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FOREWORD 


This  volume  is  one  of  nine  individually  bound  volumes  that  constitute 
the  Phase  II  Final  Report  "Study  of  Embedded  Computer  Systems  Support" 
for  Contract  F33600-79-C-0540.  The  efforts  and  analyses  reported  In 
these  volumes  were  sponsored  by  AFLC/LOEC  and  cover  a  reporting 
period  from  September  1979  through  September  1980. 

The  nine  volumes  are 
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I  Executive  Overview  (CDRL  05) 
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V  Requirements  Baseline:  Communications  - 
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VI  Requirements  Baseline:  Electronic  Warfare 
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VII  Requirements  Baseline:  Operational  Flight 
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VIII  ECS  Technology  Forecast  (CDRL  03) 

IX  National  Software  Works  Investigation 
(CDRL  04) 
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1.  OPERATIONAL  FLIGHT  PROGRAMS 


1.1  BACKGROUND 

Airborne  weapon  systems  are  traditionally  partitioned  into  airframe, 
propulsion,  and  avionics  with  avionics  generally  defined  as  including  all 
electronics  on  board  the  air  vehicle.  Also  in  a  historical  sense,  avionic 
suites  evolved  by  the  addition  of  a  new  "black  box"  for  each  new  capability 
or  function  with  the  aircrew  serving  as  the  primary  integrator  of  the 
often  simultaneous  perishable  data. 

The  introduction  of  computer  resources  (computers  and  computer 
programs)  provided  not  only  the  potential  for  greatly  improving  weapon 
system  capability,  flexibility,  and  performance  but  the  capability  to 
integrate  the  avionics  functions  and  reduce  aircrew  work  load  to  an 
efficient  management  level.  In  time,  computer  resources  in  weapon 
systems  became  known  as  embedded  computer  systems  and  the  airborne 
computer  programs  that  integrated  avionic  functions  became  known  as 
Operational  Flight  Programs  (OFP).  The  OFP  is  further  defined  as  that 
software  /firmware  which  executes  in  the  embedded  computer(s)  or 
subsystem(s)  within  an  avionic  suite  and  performs  functions  that  are 
integral  to  the  on  board  system.  In  essence  the  OFP  is  the  integrator 
and  controller  for  the  avionic  system/subsystem/item. 

1.2  WEAPON  SYSTEMS  CONTAINING  EMBEDDED  COMPUTER  SYSTEMS 

A  computer  using  digital  techniques  was  first  applied  to  the  MA-1 
fire  control  system  of  the  F-106  in  the  late  1950's.  The  F/FB-111  were 
the  first  major  aircraft  systems  to  use  integrated  digital  avionics.  Since 
that  time  embedded  computer  systems  have  been  used  in  varying  degrees 
in  several  aircraft  avionics  systems  and  are  used  extensively  in  most 
new  aircraft  and  missile  systems.  Major  missile  systems  such  as 
Minuteman  II  and  III  incorporate  embedded  computer  systems  in  both 


operational  flight  and  ground  based  programs.  Future  ICBM  and  cruise 
missile  systems  are  expected  to  continue  this  practice.  Those  weapon 
systems /subsystems  currently  containing  ECS  with  operational  flight 
programs  are  shown  in  Table  1-1.  This  list  is  not  intended  to  be  exhaus¬ 
tive  of  systems  bearing  the  label  OFP  but  does  include  those  systems  of 
importance  to  the  OFP  ECS  category  baseline. 

1.3  FUNCTIONS  PERFORMED  BY  OPERATIONAL  FLIGHT  PROGRAMS 

The  primary  functional  requirements  of  a  typical  USAF  avionics 
system/subsystem  subject  to  OFP  integration  or  control  are  extensive. 
Table  1-2  shows  representative  avionics  functions  grouped  according 
to  system,  sensor, and  mission  functions.  Controls  and  displays  is  an 
additional  function  which  cuts  across  the  other  functions  particularly 
in  the  area  of  display  symbology. 

Currently  aircraft  OFP's  resident  in  embedded  computers 
primarily  integrate/control  the  following  generic  avionics  functions; 

•  Navigation 

•  Controls  and  displays 

•  Radar 

•  Weapon  control/delivery 

•  Flight  control 

•  Flight  recording 

•  Engines 

•  Built-in-test 

Table  1-3  shows  the  weapon  systems/subsystems  and  the  primary 
function  controlled  by  their  respective  OFP's.  Also  shown  is  the  number 
of  OFP  related  embedded  computers  in  the  ECS. 
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Table  1-1.  Weapon  Systems  Containing  OFP's 
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Mlnuteman  II /III  ICBM  SAC  Transitioned 

AN/AVQ-26  Target  Acquisition  TAC  Acquisition 

AGM-69A  Defense  Suppression  SAC  Transitioned 


Table  1-2.  Representative  Avionic  Functions 


•  System  functions 

Engine 

Fuel 

Hydraulic 

Electrical 

Lighting 

Flight  control 

Communications 

Navigation 

Built-in-test 

Environment  control 

•  Sensor  functions 
Air  data 

Attitude  and  heading 
Navigation 
Target/threat 
Data  smoothing 
Flight  recorder 

•  Mission  functions 

Departure  and  arrival 
Enroute 

Stores  management/weapon  delivery 

•  Air-to-air 

•  Air-to-ground 

Note:  Electronic  warfare  systems,  although  avionic 

functions,  are  grouped  in  a  separate  category 


Table  1-3.  ECS  Category  OFP  Primary  Functions 


2.  OFP  CATEGORY  ECS  SUPPORT  REQUIREMENTS 


The  support  of  embedded  computer  systems  which  are  made  up 
of  computer  equipment  and  computer  programs  is  based  upon  the 
experience  that  over  a  period  of  time  changes/modifications  will  be 
necessary  to  correct  deficiencies,  enhance  system  capabilities  in 
response  to  operational  need,  and  adapt  the  weapon  system  to  a  new  role 
or  mission  during  the  period  of  its  life  cycle.  Experience  also  shows 
that  system  deficiencies  and  modifications  are  frequently  more  readily 
correctable  by  altering  the  software  than  the  hardware. 

Support  requirements  are  driven  by  the  nature  of  the  embedded 
computer  system's  functional  role  in  the  weapon  system.  For  example, 
if  the  OFP  is  resident  in  an  Inertial  Measurement  Unit  (IMU)  and  navi¬ 
gation  is  the  only  ECS  function,  the  support  requirement  will  be  of 
different  magnitude  than  if  the  OFP  is  the  integrator  and  controller  for 
a  weapon  system  that  delivers  nuclear  weapons.  In  either  case  however, 
the  task  of  changing  or  modifying  the  ECS  can  be  partitioned  into  a 
definable  set  of  requirements.  These  requirements  are  often  thought 
of  as  activities  or  expressed  as  a  sequential  process.  At  a  higher  level 
abstraction,  the  requirement  may  be  viewed  simply  as  keeping  the 
weapon  system  responsive  to  operational  need. 

Operational  flight  program  support  requirements  in  the  post-PMRT 
phase  of  the  life  cycle  are  normally  the  responsibility  of  the  Air  Force 
Logistics  Command  and  are  accomplished  at  the  Air  Logistics  Centers. 
The  actual  support  requirements  for  OFP's  are  very  similar  regardless 
of  the  source  of  the  support,  i.e.,  government,  contractor,  or  a  com¬ 
bination  of  the  two.  The  following  paragraphs  discuss  the  generic  and 
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unique  post-PMRT  OFP  support  requirements  which  involve  the 
administration  and  management  of  engineering  and  technical  activities  to 
maintain  program  control  and  to  effect  changes /modifications  to  OFP 
embedded  computer  systems.  Table  2-1  summarizes  these  activities 
in  the  change  process. 

2.1  ECS  CHANGE 


2.1.1  Receive  and  Process  Requests 


The  OFP  change  process  is  initiated  with  the  receipt  of  a  deficiency 
report  or  requirements  change  request.  This  is  primarily  a  manage¬ 
ment  or  administrative  function  but  procedures  must  be  established  to 
ensure  that  all  requests  are  recorded  and  tracked  until  they  are  resolved. 
Technical  assistance  may  be  required  to  ensure  that  the  requests  are 
clearly  stated  and  understood. 


2.1.2  Preliminary  Analysis  and  Problem /ge-ie/ency  Definition 


The  change  process  requires  a  certain  amount  of  change  analysis 
effort  for  every  change  entered  into  the  system.  Some  filtering  must  be 
accomplished  to  assure  that  only  serious  candidate  changes  involving 
software  problems  are  considered.  The  goal  is  to  realize  a  normal 
change  processing  cycle. 


2. 1.3  Preliminary  Resource  Allocation  and  Scheduling 


A  common  practice  is  to  collect  all  change  requests  between 
major  updates  and  process  them  in  one  change  cycle.  This  permits 
coordination  and  planning  for  orderly  accomplishment  of  the  change 
cycle.  However,  provisions  must  be  made  for  accommodating  urgent 
or  emergency  changes. 
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2.2  CHANGE  ANALYSIS  AND  SPECIFICATION 

2.2.1  Feasibility 

Analyze  system  specifications,  improvements  already  underway, 
any  proposed  system  changes  to  ensure  system  integrity.  Determine 
any  new  hardware/ software  interfaces.  Ensure  that  the  requirements 
are  feasible  and  testable. 

2.2.2  Requirements  D-ecompaaition/Definition 

Examine  the  requirements  imposed  by  each  software  change 
request  and  determine  how  they  relate  to  the  existing  requirements. 
Determine  software,  hardware,  and  system  impacts.  Examine  alter¬ 
native  design  approaches.  Document  results  of  technical  evaluation. 

In  those  cases  where  the  change  is  to  be  accomplished  by  contract  or 
with  contractor  assistance,  a  change  proposal  (Requirement  8)  will 
be  required. 

2.2.3  Preliminary  Design 

Accomplish  preliminary  design  and  testing  approach.  Determine 
impact  of  implementing  a  change  request  on  the  support  system. 

Prepare  documentation  and  conduct  Preliminary  Design  Review  (PDR). 

2.2.4  Detailed  Design 

Prepare  flow  charts,  logic  diagrams,  equations,  and  narrative 
description,  sufficiently  detailed  to  provide  basis  for  actual  coding. 
Complete  definition  of  data  base  at  the  software  segment,  program, 
function  module,  and  routine  levels;  include  number,  type,  and  structure 
of  tables  and  description  of  items  in  the  tables.  Define  all  elements 
as  critical  or  noncritical.  Develop  detailed  draft  of  validation  test  plan. 
Conduct  Critical  Design  Review  (CDR)  to  confirm  that  the  design  meets 
its  development  requirements  and  is  defined  sufficiently  to  permit 
start  of  coding. 
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2.2.5  Generate  Change  Proposal 


This  activity  documents  the  change  proposal  and  seeks  approval 
from  either  the  Computer  Program  Configuration  Sub-board  (CPCSB) 
or  the  Configuration  Control  Board  (CCB)  depending  upon  the  nature  and 
extent  of  the  change  or  changes.  This  should  be  a  meaningful  review 
and  formal  approval,  not  just  a  management  formality. 

2.3  ENGINEERING  DEVELOPMENT  AND  UNIT  TEST 

2.3.1  Develop  the  Change 

Code,  debug,  and  check  out  the  routines.  Debugging  will  ensure 
compilation  and  checkout  will  ensure  execution. 

2.3.2  Perform  Engineering  Tests 

Conduct  testing  of  coded  elements  and  integrate  software  segment 
to  produce  new  master  tape. 

2.4  SYSTEM  INTEGRATION  AND  TEST 

2.4.1  Test  ECS  System  Performance 

Conduct  testing  of  entire  integrated  ECS  system,  including  soft¬ 
ware  developed  and  tested  during  development  and  other  interfacing 
hardware  and  software.  For  most  OFP  changes  some  form  of  veri¬ 
fication  and  validation  will  be  necessary.  To  be  effective  this  should 
be  an  independent  activity. 

2.4.2  Test  Weapon  System  Performance 

Test  integrated  and  validated  ECS's  in  the  operational  environ¬ 
ment  with  all  other  associated  systems.  This  will  usually  involve  some 
degree  of  flight  testing  for  OFP  change. 

2.4.3  Produce  Test  Reports 

Analyze  simulation  and  flight  test  results  to  ensure  that  the  as- 
coded  software  changes  satisfy  the  requirements  and  have  no  adverse 
affects  on  the  operation  of  the  unchanged  parts  of  the  OFP  and  ECS. 
Implicit  in  their  activity  is  a  final  review  and  decision  to  issue  a  new 
release. 


2.5  CHANGE  DOCUMENTATION 


2.5.1  Document  ECS  Change 

Formalize  the  documentation  of  the  specific  ECS  change  or 
changes. 

2.5.2  Update  ECS  Baseline 

This  activity  creates  the  new  baseline  for  the  entire  ECS  through 
update  of  appropriate  specifications  and  associated  documentation. 

2.5.3  Configuration  Control 

This  activity  formalizes  and  controls  the  new  baselines  for 
the  OFP  and  the  ECS. 

2.6  CERTIFICATION  AND  DISTRIBUTION 

2.6.1  Certify  Documentation 

Certification  is  an  administrative  procedure  performed  to  ensure 
that  enough  evidence  is  available  to  state  with  near  certainty  that  the 
system  will  satisfy  the  user' s  needs.  It  is  performed  after  the  system 
testing  has  been  completed.  Certification  embodies  all  the  ECS  testing 
and  evaluation,  verification,  validation,  and  operational  testing  and 
evaluation  activities  have  been  performed. 

2.6.2  Distribute  Revised  ECS  Data 

Distribute  revised/updated  OFP  and  related  system  changes  to 
hardware,  support  system,  training,  technical  publications,  and  support 
documentation. 

2.6.3  Provide  Installation/Procedures /Instructions 


2.7  UNIQUE  SUPPORT  REQUIREMENTS 

Embedded  computer  systems  that  have  a  first  or  second  level 
interface  to  a  nuclear  weapon  as  defined  in  AFR  122-9  fall  in  a  special 
category.  This  includes  software  used  by  automata  which  control  critical 
functions  of  a  nuclear  weapon  (first  level  interface)  or  which  respond  to 
or  transmit  information  to  automata  having  a  first  level  interface.  In 
this  context  automata  includes  automatic  processors,  microprocessors, 
computers,  decoders,  controllers,  and  may  include  their  associated 
peripheral  equipment.  The  following  requirements  are  unique  to  this 
special  category. 

2.7.1  Nuclear  Safety  Design  Criteria 

Design  of  an  ECS  system  which  has  a  first  or  second  level  inter¬ 
face  with  a  nuclear  weapon  must  include  positive  measures  whose  goal 
is  to  prevent  the  malfunction  or  accident  to  a  single  component,  and 
to  prevent  deliberate  action  which  will  cause  prearming,  arming, 
launching,  jettisoning  or  releasing  nuclear  weapons,  or  producing  a 
nuclear  yield  except  when  directed  by  competent  authority. 

2.7.2  Nuclear  Safety  Test  Criteria 

For  ECS  having  a  first  or  second  level  interface  to  a  nuclear 
weapon,  a  nuclear  safety  cross  check  analysis  is  required.  This 
includes  examination  of  coding,  flows,  and  requirements  to  ensure  that 
software  errors  do  not  contribute  to  nuclear  accidents  of  the  sort 
described  in  Section  2.7.1. 
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3.  OFP  CATEGORY  ECS  SUPPORT  CONCEPTS 


3.1  BACKGROUND 

The  concept  for  support  of  embedded  computer  system  category 
OFP  is  known  as  Avionics  Integration  Support  Facility  (AISF).  Although 
engineering  laboratories  for  OFP  support  were  being  established  in  the 
early  1970's  at  China  Lake  NAS  for  both  Navy  and  Air  Force  versions 
of  the  A-7  and  at  McClellan  AFB  for  the  F/FB-111,  the  term  AISF 
emerged  in  the  mid-1970's.  The  initial  facilities  were  established 
primarily  as  software  (OFP)  support  facilities  because  software  was 
believed  to  be  the  major  problem.  However,  with  the  release  to  Navy 
field  units  of  the  first  organically  revised  OFP  by  the  China  Lake 
facility  in  early  1974,  and  for  the  F/FB-111  later  that  same  year  by 
McClellan,  the  capability  of  these  facilities  was  more  fully  understood. 

It  became  apparent  particularly  during  the  development  and  initial 
operation  of  the  F/FB-111  AISF,  that  these  facilities,  depending  upon 
their  configuration,  could  do  much  more  than  just  support  reprogramming 
of  the  OFP.  This  notion  was  also  supported  by  a  growing  need  and 
recognition  that  hardware  support  as  well  as  system  support  were  equally 
important  and  that  their  support  could  be  accomplished  within  the  AISF 
concept.  Furthermore,  with  popularization  of  the  terms  computer 
resources  and  embedded  computer  systems,  the  emphasis  shifted  towards 
system  or  ECS  support  requirements  rather  than  separate  concepts  and 
facilities  for  hardware,  software,  and  system  support  needs. 

3.2  ECS  HARDWARE  AND  SOFTWARE  SUPPORT 

The  current  OFP  ECS  support  concept  assigns  computer  equip¬ 
ment  (hardware)  and  computer  program  (software)  support  to  an  Item 
Manager  (IM)  or  System  Manager  (SM)  with  the  software  support  facility 
(AISF)  collocated  with  and  responsive  to  the  weapon  system  manager. 


The  OFP  ECS  category  support  concept  envisions  support  of  computer 
equipment  (hardware)  in  the  traditional  sense,  i.  e. ,  Technology  Repair 
Center  (TRC)  with  computer  program  (software)  support  being  provided 
by  engineering  laboratories  (AISF's)  established  within  the  engineering 
divisions  at  the  ALC's.  Underlying  the  concept  is  an  attempt  to  collocate 
software  management  with  associated  hardware  management  to  retain 
control  over  system  performance. 

3.3  ECS  SUPPORT  MANAGEMENT 

The  system  manager  is  responsible  for  overall  weapon  system 
support.  He  exercises  this  responsibility  directly  and  through  various 
item  managers  for  hardware  support  with  both  the  SM  and  IM  ECS 
computer  program  support  being  provided  primarily  by  or  channeled 
through  the  appropriate  engineering  organization. 

3.4  ECS  CATEGORY  OFP  -  AISF  CONCEPT 

Currently  the  AISF  established  within  the  engineering  divisions 
is  described  as  an  engineering  laboratory  composed  of  the  engineering 
and  scientific  capability  required  to  accomplish  the  requirements  listed 
in  Table  2-1.  The  AISF  concept  shown  pictorially  in  Figure  3-1,  brings 
together  all  the  tools  and  skills  required  for  the  support  of  the  OFP's 
resident  in  the  embedded  computer  systems. 

3.5  AISF  FUNCTIONS 

An  AISF,  which  is  normally  established  for  the  deployment  phase, 
consists  of  the  equipment,  data,  and  people  involved  in  the  continuous 
process  of  embedded  computer  system  revision  and  update  throughout 
the  remainder  of  the  weapon  system  life  cycle.  To  accomplish  the 
support  requirements,  an  AISF  provides  the  capability  to 

•  Identify  change  requirements  for  enhancements,  mission 
changes,  additions  of  new  sensors/subsystems,  and 
correction  of  deficiencies/errors 

•  Establish  a  management  system  for  review,  approval,  and 
control  of  block  changes  proven  technically  achievable 
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Figure  3-1.  Avionics  Integration  Support  Facility 


•  Develop  updated/modified  OFP's  in  response  to 
engineering  requests  and  approved  changes 

•  Perform  verification  and  validation  (V&V)  of  change 
candidates  through  use  of  simulation/integration 
facilities,  flight  test,  and  procedures 

•  Review  final  development,  verification,  and  flight  test 
results  for  certification  and  field  release  of  updated 
OFP's 

•  Update  related  system  changes  to  hardware,  OFP 
support  systems,  training,  technical  publications,  and 
support  documentation 

An  important  additional  functional  use  of  an  AISF  concerns  the 
capability  to  support  the  PMRT  process.  Depending  upon  the  availability 
of  the  AISF  or  even  portions  of  the  AISF  prior  to  PMRT,  AFLC  can  be  in 
a  position  to  support  independent  assessment  of  the  deliverable  systems/ 
products.  It  can  also  demonstrate  weapon  system  supportability  which 
is  an  important  part  of  combat  readiness.  By  participating  in  the  AISF 
acquisition/development,  weapon  and  support  system  training  is  accom¬ 
plished.  Once  again,  depending  upon  the  completeness  of  the  AISF,  AFLC 
can  perform  independent  verification  and  validation  in  conjunction  with 
or  prior  to  PMRT. 

3.6  AISF  COMPONENTS 

The  basic  components  of  an  AISF  are  shown  in  Figure  3-2.  This 
simplified  form  is  used  to  facilitate  delineation  and  comparison  of 
representative  support  systems  in  Section  4.  The  following  paragraphs 
describe  the  components  of  an  AISF  in  terms  of 

•  Host  processor  (off-line) 

•  Dynamic  simulation  system 

•  Simulation  host  processor 

•  Hardware  interface 

•  Flight  proces sor( s) 

•  Avionics  systems /subsystems 

•  Flight  test 
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AISF  Basic  Components 


3.6.1  Host  Processor  (Off-line) 

Off-line  computational  capability  comprised  of  medium  to  large 
scale  computers  is  used  for  engineering  data  management,  simulation 
and  flight  test  data  reduction  and  analysis,  configuration  management, 
off-line  interpretive  computer  simulations,  various  support  and 
debugging  tools,  cross-assemblers  and  compilers,  special  simulation 
routines,  and  other  software  related  tasks  that  can  be  best  accomplished 
away  from  the  dynamic  simulation  environment. 

3.6.2  Dynamic  Simulation  System 

The  dynamic  simulation  system  is  made  up  of  a  front  end  mock-up 
of  the  weapon  system  and  the  following  four  elements. 

3. 6. 2.1  Simulation  Host  Processor 

The  simulation  host  processor  is  usually  a  standard,  off-the-shelf, 
qualified  minicomputer  and,  depending  upon  its  size  and  capability,  may 
also  be  used  to  accomplish  many  or  all  of  the  off-line  host  processor 
functions.  However,  this  computer  primarily  provides  the  capability 
to  drive  the  embedded  computer  flight  processor  in  a  real  time,  closed 
loop  simulation  mode  and  to  collect  data  from  the  flight  computer  while 
the  simulation  is  running.  This  data  can  then  be  used  to  analyze  the 
performance  of  the  operational  software.  The  software  resident  on  the 
simulation  host  processor  would  include 

•  Software  routines  to  control  and  monitor  the  interface 
to  the  avionics  embedded  computer 

•  Software  routines  to  process  data  sent  to  and  from  the 
avionics  subsystems 

•  Simulations  for  closed  loop  operation  with  the  operational 
flight  program 

•  Support  software  unique  to  the  minicomputer  such  as 
compilers,  assemblers,  and  operating  systems 
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3. 6. 2. 2  Hardware  Interface 

This  element  between  the  simulation  processor  and  the  flight 
processor  will  consist  of  interface  for  loading,  starting,  stopping, 
monitoring,  controlling,  simulating,  and  displaying  those  functions  that 
are  inherent  to  a  dynamic,  closed  loop  simulation  of  an  avionics  suite. 

The  hardware  interface  would  normally  take  the  form  of 

•  A  computer  monitor  and  control  function  which 
interfaces  with  the  internal  signals  of  a  flight 
computer  for  the  purpose  of  monitoring  the  flight 
computer's  central  processing  unit  and  controlling 
the  operation  of  the  flight  computer  such  as  chang¬ 
ing  its  internal  status,  starting  and  halting  program 
execution,  and  like  functions 

•  Hardware  interface  adaptor  units  for  switching 
and  signal  conditioning  (D/A  and  A/D),  power 
distribution,  and  control 

3. 6. 2. 3  Flight  Processor(s) 

Addition  of  the  flight  processor  to  the  simulation  host  processor 
and  interface  hardware  results  in  a  Software  Test  Bed  (STB),  sometimes 
called  a  dynamic  simulation  system,  and  provides  the  capability  for 
OFP  testing. 

3. 6. 2.4  Avioncs  System/Subsystems 

Only  those  systems/subsystems  that  affect  the  operation  of  the 
operational  program  may  be  required  for  OFP  test.  However,  if  hard¬ 
ware  or  systems  integration  and  test  is  the  objective,  the  entire  avionic 
suite  may  be  required.  This  element,  called  an  Integration  Test  Bed 
(ITB),  rounds  out  the  ground  based  engineering  laboratory. 

3.6.3  Flight  Test 

Flight  testing  requires  use  of  an  instrumented  aircraft,  recording 
equipment,  and  an  appropriately  instrumented  flight  test  range.  Flight 
test  is  performed  for  comparison  and  verification  of  simulation/integration 
test  results.  Data  reduction  and  analysis  for  both  dynamic  simulation 
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cases  and  actual  flight  tests  can  be  performed  on  the  off-line  host 
processor  or  in  some  cases  on  the  simulation  host  processor  depending 
upon  the  relative  capabilities  of  the  processors  and  the  configuration 
of  the  particular  AISF. 

3.7  ORGANIZATIONAL  CONCEPT 

The  organizational  concept  and  major  interfaces  required  for 
OFP  support  are  shown  in  Figure  3-3.  The  concept  establishes  MMEC 
within  the  engineering  division  as  the  computer  resource  focal  point. 
The  organizational  relationships  both  internal  and  external  to  the  ALC 
are  defined  in  the  various  Computer  Resources  Integrated  Support 
Plans  (CRISP)  and  Operational/Support  Configuration  Management 
Procedures  (O/SCMP)  for  each  individual  weapon  system  ECS. 
Organizational  relationships  are  further  discussed  in  Section  4 
"Representative  Systems  and  Support  Systems.  " 


•  SYSTEM  PERFORMANCE  •  USERS 

•  SYSTEM  INTEGRITY  •  TEST  RANGES 

•  ECS  HARDWARE  •  PUBLICATIONS 

•  SUPPORT  SYSTEM  HARDWARE  •  FACILITIES 

•  SUPPORT  SYSTEM  SOFTWARE  •  PERSONNEL 

•  AUTOMATIC  TEST  EQUIPMENT  •  FUNDING 

•  AIRCREW  TRAINING  DEVICES  •  CONTRACTOR(S) 

•  COMMUNICATIONS  ELECTRONICS 

•  ELECTRONIC  WARFARE 


Figure  3-3.  OFP  Support  Management/Technical 
Interfaces 
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4.  REPRESENTATIVE  SYSTEMS  AND  SUPPORT  SYSTEMS 


A  more  detailed  investigation  and  analysis  of  representative  weapon 
systems  with  emphasis  on  their  support  systems  is  presented  in  this 
section.  The  selection  of  both  aircraft  and  missile  systems  within  the 
OFP  ECS  category  was  made  to  ensure  the  broadest  possible  coverage  of 
the  category  to  establish  the  current  support  baseline.  The  systems 
selected  along  with  rationale  for  their  selection  follows: 

•  F/FB-111  -  first  highly  integrated  aircraft  weapon  system 
to  reach  operational  status;  multi -mission;  operated  by  two 
MAJCOMS;  has  major  digital  subsystems  (PAVE  TACK, 

SRAM);  the  support  system  is  operational. 

•  F/RF-4  -  first  major  digital  update  (Class  V  modification) 
to  an  existing  weapon  system;  multi-mission;  both  the  ECS 
and  support  system  are  in  acquisition. 

•  F-16  -  first  major  weapon  system  in  acquisition  concurrent 
with  or  subsequent  to  DOD  and  Air  Force  ECS  policy  and 
guidance  initiatives;  multi-national  ownership  and  use;  both 
the  weapon  and  support  system  are  in  acquisition. 

•  Minuteman  II/ III  -  major  unmanned  weapon  system;  involves 
nuclear  weapons;  PMRT  long  after  system  was  operational. 

4.1  F/FB-111  WEAPON  SYSTEM  DESCRIPTION 

The  F/FB-111  is  a  twin  engined,  high  performance,  variable 
geometry  fighter  bomber.  Its  primary  mission  role  is  precision  bombing 
and  all  weather  night  attack.  The  FB-111A  has  the  additional  capability 
for  strategic  nuclear  weapons  delivery.  The  F-111D,  F-111F,  andFB-lllA 
have  highly  integrated  digital  avionics  suites.  Major  avionic  differences 
are  the  doppler  radar  and  moving  map  display  on  the  FB-111A  and  F-111D; 
an  astrocompass  and  SRAM  on  the  FB-111A;  and  a  digital  stores  manage¬ 
ment  system,  an  advanced  display  capability,  and  an  attack  radar  on  the 
F-111D. 


These  three  aircraft  use  common  digital,  reprogrammable 
computers  (2  IBM  4  pi,  16  bit,  16K  word)  and  a  common  analog  to 
digital  converter,  multiplexer  set.  The  different  capabilities  of  the 
three  aircraft  are  achieved  through  differing  mechanization  of  the  OFP's 
resident  in  the  Weapon  Delivery  Computer  (WDC)  and  the  General 
Navigation  Computer  (GNC). 

4.1.1  F/FB-111  Embedded  Computer  Systems 

The  avionic  functions  of  the  F/FB-111  aircraft  series  are 
accomplished  through  incorporation  of  a  highly  interactive  and  integrated 
embedded  computer  system.  The  operational  flight  programs  for  each 
aircraft  reside  in  the  general  navigation  computer,  the  weapons  delivery 
computer,  and  the  navigation  computer  (NCU)  with  the  OFP's  within  the 
GNC  and  WDC  performing  the  operations  which  integrate  and  control 
the  avionics  system.  The  GNC,  WDC,  and  NCU  interface  with  a  multi¬ 
plexer  converter  which  in  turn  interfaces  with  the  various  avionic 
functional  elements.  A  diagram  of  the  computer  equipment  and  computer 
program  functions  integral  to  the  F/FB-111  are  shown  in  Figure  4-1. 

In  Figure  4-2  a  simplified  version  of  the  ECS  shows  both  the  generic 
functions  and  F/FB-111  nomenclature. 

4.1.2  F/FB-111  OFP  Change  Process 

A  block  change  consists  of  a  number  of  OFP  changes  which  are 
concurrently  processed  and  integrated  into  a  new  baseline  OFP  over  a 
specified  period  of  time.  The  F/FB-111  block  change  process  is  shown 
in  Figure  4-3  and  summarized  in  Table  4-1  for  ease  of  comparison  with 
other  representative  system  change  processes.  These  changes  affect 
only  the  OFP  and  are  accomplished  within  the  current  ECS  hardware 
baseline.  The  number  of  changes  attempted  in  any  given  cycle  is  a 
function  of  user-established  priorities  and  complexity  or  difficulty  of 
the  proposed  change.  Flexibility  in  the  change  process  is  achieved  by 
providing  for  unplanned  or  out  of  cycle  changes  depending  upon  user 
urgency  and  a  "Configuration  Freeze"  late  in  the  change  cycle. 
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Figure  4-1.  F/FB-111  Avionics  System 
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Figure  4-2.  F/FB-111  Embedded  Computer  System 
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Table  4-1.  F/FB-111  OFP  Block  Change 

Cycle  (18  Months) 
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Mission  and  weapon  control 
program  produced 

! 

• 

Laboratory  verification  and 
evaluation  completed 

Formal  Test 

• 

Three  phase  labor- 

• 

OFP  block  change  configuration 

and 

atory  test 

freeze 

Evaluation 

• 

Instrumented  engi- 
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Figure  4-3.  F/FB-111  OFF  Change  Process 


The  duration  of  the  change  cycle  (currently  18  months)  is  rigidly 
adhered  to  and  is  based  on  several  considerations  including  user  request, 
support  resources,  related  system  updates,  crew  training,  and  lead  times 
for  documentation  update.  The  OFP  block  change  process  is  continuous, 
with  each  block  change  containing  only  OFP  changes  which  do  not  impact 
hardware,  can  be  accomplished  within  existing  resources,  and  do  not 
disrupt  the  scheduled  cycle  time. 

4.1.3  F/FB-111  QFP  Support  Interfaces 

The  F/FB-111  block  change  process  is  highly  technical  with 
extensive  engineering  oriented  interaction  internal  to  the  engineering 
organization  as  well  as  external,  such  as  with  the  system  manager 
and  user.  In  the  case  of  the  F/FB-111,  three  OFP  change  cycles 
involving  seven  OFP's  are  in  progress  continuously  and  simultaneously 
in  support  of  the  FB-111A,  F-111D  and  F-111F.  The  engineering 
organization  (MMEC)  owns  and  supports  the  AISF  with  MMECP  respon¬ 
sible  for  the  technical  management,  planning,  and  direction  of  the 
complete  OFP  change  cycle,  and  for  the  development  and  implementation 
of  all  OFP  changes.  The  primary  organizational  interfaces  for  OFP 
support  are  the  system  manager  in  coordination  with  the  users  (TAC  and 
SAC)  for  operational  requirements  and  internal  to  AFLC/ALC  for  other 
requirements  such  as  personnel,  facilities,  equipment,  contracting, 
and  technical  publication. 

4.1.4  F/FB-111  OFP  ECS  Hardware  Support 

Determining  whether  or  not,  or  to  what  extent,  ECS  hardware  is 
impacted  is  normally  accomplished  during  the  feasibility  phase.  This 
activity  may  require  use  of  the  full  range  of  equipment  and  skill  available 
in  the  support  facility.  Once  the  determination  is  made  that  a  proposed 
change  requires  both  ECS  hardware  and  software  modification  or  just 
hardware,  the  engineering  package  is  referred  to  the  systems  manager 
for  processing  in  accordance  with  hardware  procedures.  However,  this 
does  not  preclude  accomplishing  the  OFP  portion  of  the  change  by  the 
OFP  support  facility. 
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In  addition  to  isolation  of  problems  to  hardware  or  software  or 
determining  the  impact  of  proposed  changes  to  hardware  or  software, 
hardware  support  is  provided  by  the  OFP  support  facility  in  the  area  of 
simulation  for  a  wide  variety  of  equipment  malfunctions,  failures,  and 
degraded  performance.  This  capability  is  also  applied  to  analysis  of 
troublesome  items  that  are  cleared  by  normal  test  and  repair  procedures 
but  do  not  perform  in  the  operational  environment. 

4.1.5  F/FB-111  OFP  ECS  Software  Support 

The  engineering  activities  required  during  the  OFP  change  process 
are  under  the  direction  of  MMEC  and  are  accomplished  in  an  engineering 
laboratory  located  at  SM-ALC.  This  laboratory  and  associated  facilities 
and  equipment,  which  are  described  in  the  following  paragraphs,  consists 
of: 

•  Off-line  computer  support 

•  Dynamic  simulation 

•  Avionics  integration 

•  Instrumented  flight  test  aircraft 

•  Subsystem  test 

4 . 1 .  5 . 1  Off-line  Computer  Support 

The  off-line  computational  support  required  for  changing /modifying 
F/FB-ill  OFP's  is  provided  by  use  of  two  Interdata  8/32  minicomputer 
systems  and  a  PDP  11/40  minicomputer  system.  Additional  capability 
is  provided  by  a  remote  terminal  to  an  IBM  360-65  computer  complex 
located  at  OO-ALC.  This  facility  is  presently  the  only  source  available 
for  OFP  assemblies. 

4. 1.5. 2  Dynamic  Simulation 

Separate  dynamic  simulation  systems  for  the  F-111D  and  FB-lllA/ 
F-111F  provide  a  laboratory  capability  to  exercise  the  flight  computers 
with  resident  OFP's  in  a  fidelity  simulated  flight  environment.  Each 
simulation  system  equipment  configuration  consists  of  host  processors. 
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special  interface  hardware,  the  actual  flight  computers  with  their  OFP's, 
and  an  aircraft  cockpit  which  also  serves  as  a  test  station.  The  major 
elements  of  the  avionic  integration  support  facility  are  depicted  in 
Figure  4-4.  The  dynamic  simulation  system  complex  is  shown  in 
Figure  4-5  and  in  simplified  form  in  Figure  4-6  for  ease  of  comparison 
to  subsequent  discussions  of  the  other  dynamic  simulation  systems. 

4. 1.5.3  Avionics  Integration 

Avionics  integration  equipment  in  the  F/FB-111  AISF  provides 
the  capability  to  do  static  integration  and  test  of  the  revised  OFP's  with 
the  avionics  system.  This  integration  test  equipment  (ITE)  is  for  the 
most  part  the  same  equipment  used  during  the  initial  development  of  the 
OFP's.  Therefore,  it  can  be  used  for  on-line  implementation  and 
evaluation  of  trial  solutions  as  well  as  final  system  compatibility  tests. 
The  ITE  also  provides  the  means  to  recreate  flight. problems  and  check 
hardware/ software  interfaces.  This  equipment  is  used  extensively 
throughout  the  OFP  change  process. 

4.1.5. 4  Instrumented  Flight  Test  Aircraft 

The  final  check  on  revised  OFP  performance  is  accomplished  by 
actual  flight  test.  The  flight  test  capability  includes  aircraft  equipped 
with  instrumentation  designed  specifically  for  monitoring  and  recording 
OFP  flight  performance.  Combined  with  associated  data  reduction  and 
analysis  equipment  in  the  support  facility,  this  is  used  for  final  definition 
and  verification  of  ECS  performance. 

4. 1.5.  5  Subsystem  Test 

The  F/FB-111  AISF  also  contains  a  subsystem  test  area.  This 
capability  is  ECS  hardware  oriented  and  has  evolved  as  an  extension  to 
the  basic  software  support  capability  envisioned  in  the  original  imple¬ 
mentation  plans.  The  primary  motivation  for  acquiring  this  capability 
stems  from  an  ECS  subsystem  support  viewpoint  rather  than  just  a  soft¬ 
ware  viewpoint.  It  is  described  by  SM-ALC  personnel  as  a  necessary 
part  of  the  support  facility  in  terms  of  the  "total  utility"  of  the  F/FB-111 
AISF.  Basically,  it  provides  in  the  support  facility  the  capability  for 
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F /FB -111  Avionics  Integration  Support  Facility 


j  nnigingEgiiSE 


Figure  4-5.  F-lll  OFP  Dynamic  Simulation  System  C 
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ECS  hardware  analysis  in  a  problem  isolation  or  problem  solving  mode. 

It  also  provides  a  test  bed  environment  for  hardware  development/ 
evaluation  with  regard  to  new  ECS  replacement  hardware  as  well  as 
development  of  special  tools  or  equipment  in  the  area  of  ECS  hardware 
reliability,  test,  and  maintenance.  This  capability  is  largely  micro¬ 
processor  based  and  is  versatile  in  supporting  new  subsystems  under 
development  which  incorporate  distributed  microprocessing.  Micro¬ 
processors  are  also  presently  used  to  reduce  several  of  the  large  sub¬ 
system  testers  to  two-man  portable  test  aids  for  the  F/FB-111.  These 
test  aids,  with  minor  modification,  have  applicability  to  other  embedded 
computer  systems.  The  number  and  type  of  microprocessor  development 
systems  is  presented  in  the  automatic  test  equipment  baseline. 

4.  1.5.6  Assessment  of  F/FB-111  Support  Posture 

The  F/FB-111  AtSF  provides  comprehensive  software  support  to 
the  F-111D,  F-111F  and  FB-111A.  The  equipment  is  up-to-date  with 
only  minor  limitations  due  to  some  dependency  on  remote  off-line  host 
processor  support.  MMEC  is  responsible  for  OFP  changes  and  main¬ 
taining  the  support  facilities.  Automated  tools  for  documentation  and 
configuration  management  are  needed.  The  AISF  is  managed  and  con¬ 
trolled  by  government  personnel  with  technical  staffing  consisting  largely 
of  on-site  contractor  personnel  with  back-up  at  contractor  facilities. 

The  experience  level  of  both  government  and  contractor  personnel  is 
high.  Future  plans  call  for  the  development  of  a  unique  F-111F/PAVE 
TACK  dynamic  simulation  system  for  support  of  the  F-111F  and  the 
PAVE  TACK  interface.  Support  for  PAVE  TACK  will  be  accomplished 
on  the  PAVE  TACK  AISF  at  WR-ALC.  The  AISF,  although  operating 
essentially  at  a  level  of  effort,  is  postured  for  and  is  providing  effective 
and  responsive  OFP  support  and  is  gradually  extending  its  capability  for 
a  broad  range  of  ECS  support  tasks. 


The  F/FB-111  AISF  provided  the  basis  for  the  emergence  of  the 
current  AISF  concept  and  is  now  extending  the  concept  into  a  wider  support 
role  in  the  area  of  avionics  hardware  support  and  by  extending  the  AISF 
to  the  flight  line  through  development  and  support  of  portable  test  tools 
and  aids.  Finding s / rema  rks  concerning  the  F/FB-111  AISF  current 
capability  to  support  the  requirements  are  presented  in  Table  4-2. 

4.2  F-16  WEAPON  SYSTEM  DESCRIPTION 

The  F-16  is  a  single  engined,  high  performance  fighter  bomber. 

Its  primary  mission  role  is  air  superiority  and  precision  bombing. 
Procurement  and  production  is  being  accomplished  according  to  a 
June  1975  memorandum  of  understanding  between  the  government  of 
the  United  States  and  the  governments  of  Belgium,  Denmark,  the 
Netherlands,  and  Norway. 

The  aircraft  weapon  system  uses  seven  digital  computers/ 
microprocessors  including  a  reprogrammable  Fire  Control  Computer 
(FCC),  (Delco  362F-2,  16  bit,  32K  word)  which  serves  as  a  central 
computer.  The  fire  control  computer  OFP  implements,  integrates, 
and  controls  avionic  system  functions.  The  other  airborne  processors 
are  firmware  reprogrammable. 

4.2.1  F-16  Embedded  Computer  System 

The  avionic  functions  of  the  F-l6  aircraft  are  distributed  and 
communicate  over  a  dually  redundant  MIL-STD  1553  multiplex  bus 
system  under  primary  control  of  the  fire  control  computer,  with  backup 
bus  control  in  a  degraded  mode  provided  by  the  Inertial  Navigation  Set 
(INS).  The  bus  controller,  primary  or  backup,  initiates  all  traffic  over 
the  data  buses  by  issuing  commands  to  remote  terminals  (avionic  sub¬ 
systems)  to  transmit  or  receive  data  and  also  determines  the  bus  (A  or  B) 
to  be  used  for  the  transmission.  The  AN/ALR-69  threat  warning  system 
is  a  reprogrammable  radar  warning  system  which  is  not  connected  to 
the  multiplex  bus.  This  system  is  discussed  further  in  the  Electronic 
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Table  4-2.  F/FB-111  Support  Status 


R  equirement 

Findings  /Rema  rks 

ECS  Change 

Procedures  were  established  over  a  period  of 
time,  are  thorough  and  well  implemented.  Change 
candidates  and  corresponding  workloads  negotiated 
with  user  essentially  to  conform  with  predetermined 
resource  expenditures. 

Change  Analysis 
and 

Specification 

Activities  and  procedures  are  formalized  and  comply 
with  AFR  800-14.  Locally  developed  procedures 
and  terminology  often  do  not  easily  relate  to  similar 
activities  of  development  command. 

Engineering 
Development 
and  Unit  Test 

Activities  generally  conform  with  standard  develop¬ 
ment  practices.  Terminology  sometimes  mis¬ 
leading,  i.e.,  PDR  and  CDR  not  mentioned. 

Block  change  configuration  not  established  until 
test  phase. 

System  Inte¬ 
gration  and 

T  est 

Integration  and  test  is  thorough  and  comprehensive 
with  extensive  user  involvement. 

Change 

Documentation 

ECS  and  support  system  baselines  documented. 

Some  locally  developed  documents  also  maintained 
such  as  Master  Software  Requirements  Document 
(MSRD).  Documentation  including  technical  order 
preparation  is  primarily  manual  and  accomplished 
at  both  government  and  contractor  facilities. 

Certification 

and 

Distribution 

System  manager  certifies  and  approves  revised 
programs  for  release.  The  use  of  standard  ALC 
technical  publication  is  time  consuming  (4  to  6 
months)  and  impairs  responsiveness. 
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Warfare  (EW)  ECS  category.  A  diagram  of  the  computer  equipment 
and  computer  program  integral  to  the  fire  control  computer  in  the  F-16 
is  shown  in  Figure  4-7.  A  simplified  diagram  of  the  F -16  ECS  is 
shown  in  Figure  4-8. 

4.2.2  F-16  OFP  Change  Process 

The  OFP  change  process  used  by  the  program  office  during  full 
scale  engineering  development  will  be  used  until  PMRT.  After  PMRT 
the  OO-ALC  computer  program  configuration  sub-board  chaired  by 
the  F-16  system  manager  is  to  have  approval  and  release  authority 
for  all  CPCI  Class  I  and  II  software  changes  which  do  not  affect  system 
equipment  and  can  be  accomplished  within  existing  support  resources. 
Operational  flight  program  updates  are  planned  to  occur  at  approximately 
18  month  intervals.  Changes  which  involve  both  hardware  and  software 
modifications  are  to  be  scheduled  on  a  case  by  case  basis,  processed 
as  ECP's  for  approval,  and  implemented  in  accordance  with  existing 
AFLC  procedures.  No  change  to  existing  AFLC  procedures  is  envisioned 
for  ECS  hardware  changes.  The  proposed  OFP  block  change  cycle  is 
shown  in  Figure  4-9  and  in  tabular  form  in  Table  4-3. 

4.2.3  F-16  OFP  Support  Interfaces 

The  F-16  OFP  change/modification  process  is  highly  technical 
with  extensive  engineering  oriented  activity  both  internal  to  Ogden  ALC 
and  external  to  the  user  and  other  support  agencies.  As  a  multinational 
use  weapon  system,  additional  interfaces  are  necessary  particularly 
at  the  system  manager  level.  This  interface  will  become  even  more 
important  should  the  F-16  become  involved  in  Foreign  Military 
Sales  (FMS). 

Current  plans  call  for  the  system  manager  to  be  responsible  for 
all  tasking  and  system  integration  including  establishing  priorities  and 
coordination  of  system  integration  efforts.  This  office  also  has 
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Figure  4-8.  F-16  Embedded  Computer  System 
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Figure  4-9.  F-16  OFP  Update  Cycle  (Planned) 


Table  4-3.  F-16  Proposed  OFP  Block  Change 

Cycle  (18  months) 


Phase /Support 
Requirement 

Engineering  Activity 

Primary  Output/Control 
Documentation 

Joint  Technical 

• 

Review  of  accumulated 

• 

Define  requirements 

Conference 

• 

change  requests 

Feasibility  studies 

• 

Establish  priorities 

• 

Approve  proposed  changes 

• 

Engineering  tests 

• 

Functional  baseline 

• 

Revise  preliminary 
ECP's 

• 

System  design  review 

• 

General  test  plan 

• 

Test  bed  program  plan 

Requirements 

• 

Engineering 

• 

Computer  program  develop- 

development 

• 

ment  specifications 

Preliminary  design  review 

• 

Trainer  modification 
requirements  definition 

• 

Configuration  control 

Design 

• 

Programming  and 
checkout 

• 

Critical  design  review 

■ 

Change  cutoff 

• 

Technical  order  and 
OFP  documentation 

• 

Trainer  modification 

T est  and 

• 

Simulation  test 

• 

Functional  configuration 

Evaluation 

• 

Integration  test 

audit 

• 

Flight  test 

• 

Physical  configuration 
audit 

• 

Test  results  analysis 

• 

Technical  order 
verification 

Demonstration 

• 

JointV&V  review 

• 

V&V  approval 

• 

User  acceptance 

OFP  Release 

• 

Technical  publication 

• 

SM  approval 

• 

Documentation 
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responsibility  for  establishing  the  weapon  system  support  facilities. 
Internal  to  OO-ALC  significant  pre-  and  post-PMRT  support  is  planned 
to  be  provided  to  the  SM  as  follows: 

•  Computer  Resources  Branch  (MMEC)  -  provide  engineering 
support  for  identifying  procurement  and  integration  of  OFP 
test  equipment  and  in  the  post-PMRT  time  period  for  problem 
resolution,  feasibility  assessment,  software  design  and 
development,  test  planning,  testing,  and  evaluation  of 

test  results. 

•  Specialized  (Test)  Engineering  Branch  (MMEI)  -  own  and 
maintain  AISF  equipment  and  facilities;  provide  manage¬ 
ment  and  schedule  of  AISF  operation  and  flight  test  functions 
including  preparation  of  test  reports. 

•  Logistics  Section,  Data  Automation  Branch  (ACDC)  -  provide 
system  analysts  and  mathematicians  for  non-ATE  support 
software  required  for  AISF  procurement  and  integration; 
during  the  post-PMRT  time  period  perform  the  maintenance/ 
modification  of  the  acquired  or  developed  support  software. 

4.2.4  F -16  OFP  ECS  Hardware  Support 

The  embedded  computer  system  support  facilities  planned  for  the 
F-16  are  primarily  focused  on  support  of  the  operational  flight  programs. 
However,  plans  include  extensive  use  of  the  dynamic  simulation  and 
integration  capabilities  for  ECS  hardware  problem  analysis  and  isolation. 
Once  problems  are  isolated  to  hardware,  the  item  is  referred  to  the 
appropriate  SM/IM  for  resolution  according  to  standing  AFLC  procedure. 
In  those  cases  where  modification  is  required  to  both  hardware  and  soft¬ 
ware,  the  software  support  facility  is  expected  to  play  a  major  role  in 
the  software  change  as  well  as  in  the  integration  and  test  of  the  approved 
modification  at  both  the  component  and  ECS  level. 

4.2.5  F-16  OFP  ECS  Software  Support 

Ogden  Air  Logistics  Center  is  presently  acquiring  the  engineering 
capability  (equipment  and  personnel)  required  to  support  the  F-16 
operational  software.  Currently  the  Avionics  Intermediate  Shop  (AIS) 
automatic  test  equipment  is  colocated  with  the  evolving  AISF  in  building 
1211.  Plans  envision  that  this  total  complement  of  equipment  when 


operational  will  be  used  in  the  post-PMRT  time  period  to  provide  support 
for  F-16  avionics  hardware,  software,  and  Automatic  Test  Equipment 
(ATE)  engineering  requirements.  This  section,  however,  is  limited 
primarily  to  discussion  of  the  equipment  configuration  being  assembled 
for  support  of  the  fire  control  computer  OFP.  The  engineering 
laboratory  and  associated  facilities  and  equipment,  which  are  described 
in  the  following  paragraphs,  consist  of: 

•  Off-line  computer  support 

•  Dynamic  simulation 

•  Avionics  integration 

•  Instrumented  flight  test  aircraft 

•  Subsystem  test 

4.  2.  5.1  Off-line  Computer  Support 

The  IBM  360-65,  resident  at  Ogden  ALC  is  slated  for  off-line 
computer  support.  The  Digital  Equipment  Corporation  (DEC)  -10  system 
general  purpose  processor,  which  is  the  host  processor  incorporated 
in  the  dynamic  simulation  system,  is  also  being  evaluated  for  use  for 
full  or  partial  off-line  software  development  and  post-simulation  data 
reduction  and  analysis.  The  DEC-10  is  in  place  in  building  1211. 

4.2.  5.2  Dynamic  Simulation 

The  dynamic  simulation  system  being  acquired  for  the  F-16  fire 
control  computer  OFP  is  a  highly  integrated  and  complex  system  con¬ 
sisting  of  the  DEC-10  system  host  processor,  discussed  above,  inter¬ 
faced  to  the  fire  control  computer  and  OFP  through  interface  hardware 
units  and  three  major  computer  controlled/driven  hardware  based 
subsystems.  The  first  of  these  subsystems,  called  control  and  moni¬ 
toring,  uses  a  PDP-11 /34,  provides  control  of  the  operator  test  station, 
and  effects  the  multiplex  bus  interface  (universal  remote  terminal)  to 
the  DEC-10  simulation  host  computer.  The  performance  monitoring  sub¬ 
system  uses  a  PDP-11/55  and  associated  peripherals  to  tie  in  a  Software 
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Control  and  Display  Unit  (SCADU),  a  Bus  Monitor  Unit  (BMU),  and  a 
Digital  Data  Recorder  (DDR)  and  to  provide  interface  with  the  control 
and  monitoring  PDP-11/34. 

The  third  subsystem  referred  to  as  the  DSS  head  up  display/ 
terrain  simulation  subsystem  also  uses  a  PDP-11 /55  to  provide  real 
time  graphics  for  head  up  display  symbology  and  three  dimensional 
perspective  transformations.  The  subsystem  is  interfaced  to  the  DEC-10 
system  host  processor  for  direct  memory  access  to  simulation  data. 

A  simplified  diagram  of  the  F-16  dynamic  simulation  system  is  shown 
in  Figure  4-10  and  in  a  different  format  in  Figure  4-11. 

4.2.  5.3  Avionics  Integration 

Another  major  element  planned  for  integration  with  the  DSS  is 
the  Avionics  Equipment  Bay  (AEB).  The  AEB  is  a  replica  of  the  forward 
section  of  the  F-16  and  contains  cables,  controls,  and  actual  avionics 
Line  Replaceable  Units  (LRU's).  The  AEB  also  includes  an  Alpha-16 
minicomputer  which  permits  stand  alone  software  and  hardware  inte¬ 
gration  and  test  for  individual  LRU's  with  partial/selective  simulation 
or  full  up  avionic  system  integration  and  test  depending  upon  the  test 
bed  configuration  or  particular  integration  or  test  objectives. 

4. 2. 5.4  Instrumented  Flight  Test  Aircraft 

Ogden  Air  Logistics  Center  plans  for  use  of  a  dedicated  F-16A 
production  configured  aircraft  with  standard  avionics  for  systems  and 
ECS  testing.  This  El  coded  aircraft  would  be  assigned  to  the  Specialized 
(Test)  Engineering  Branch  (MMET)  of  the  Service  Engineering  Division 
and  be  instrumented  to  facilitate  testing  for  system  engineering,  failure 
analysis,  prototyping,  and  support  equipment.  Plans  call  for  the  use  of 
the  Utah  test  and  training  range  for  the  majority  of  the  flight  tests  with 
data  reduction  and  analysis  being  accomplished  on  the  IBM  360-65  or  the 
DEC -10  system  DSS  host  processor,  depending  upon  the  outcome  of  the 
cost  effectivity  evaluation. 
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Figure  4-10.  F-16  Dynamic  Simulation  System  Configuration  (Planned) 


Figure  4-11.  F-16  Dynamic  Simulation  System 


4. 2.  5. 5  Subsystem  Test 

In  addition  to  the  DEC  -10  system  based  dynamic  simulation 
system  for  the  fire  control  system  OFP,  similar  OFP  software  Dynamic 
Test  Consoles  (DTC)  are  planned  for  the  Stores  Management  Set  (SMS) 
and  the  Head  Up  Display  (HUD).  Other  subsystem  test  facilities  are 
also  planned  as  follows: 

•  Radar  Engineering  Stand  (RES)  -  computer  controlled 
console  similar  to  the  one  used  by  Westinghouse  for 
initial  system  development  of  the  six  LRU's  which 
make  up  the  F-16  radar.  Primarily  for  hardware  test. 

•  Intel  MDS-800  system  -  software  preparation/development 
station  for  support  of  avionics  subsystems  containing 
8080  based  microprocessors.  Direct  OFP  support  is 
primarily  for  the  stores  management  system  with  other 
support  planned  for  automatic  test  eauipment  and 
avionic  intermediate  shop  hardware. 

•  Electrical  Standards  Set  (ESS)  -  calilwation  and  test 
equipment  for  support  of  the  AIS.  This  is  ATE  related 
and  is  associated  with  the  AISF,  primarily  because  of 
its  physical  location. 

Separate  dynamic  test  stands  or  consoles  as  part  of  the  AISF  are 
not  currently  planned  for  software  support  of  the  Inertial  Navigation  Set 
(INS),  Central  Air  Data  Computer  (CADC),  Radar  Electro-Optical  (REO), 
and  fire  control  radar.  Organic  maintenance  for  these  subsystems 
is  not  currently  planned. 

4. 2. 5. 6  Assessment  of  F -16  Support  Posture 

The  F-16  support  systems  include  a  Dynamic  Simulation  System  (DSS) 
with  an  Avionics  Equipment  Bay  (AEB)  that  provides  the  capability  to 
perform  extensive  testing  of  Fire  Control  Computer  (FCC)  changes.  The 
interface  to  the  operator  via  the  Head  Up  Display  (HUD)  simulation  and 
controls  is  excellent,  and  the  DSS  has  been  used  as  an  interim  pilot 
trainer.  Dynamic  test  consoles  for  the  stores  management  system  and 
the  HUD  will  provide  unit  development  and  test  capability  for  those  systems. 
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Significant  hardware  and  systems  tests  can  be  performed  on  the  DSS/AEB. 
In  addition,  changes  in  the  radar  system  can  also  be  tested  in  the  Radar 
Engineering  Stand  (RES)  portion  of  the  support  facilities.  The  DEC -10 
that  is  the  host  computer  for  the  DSS  has  an  effective  data  base  manage¬ 
ment  system  that  is  currently  being  used  as  the  basis  for  a  configuration 
management  system.  Support  for  the  F-16  ECS  will  be  both  organic  and 
level-of-effort  contractor.  While  the  F-16  FCC  is  pre-PMRT,  in  concept 
the  support  facility  will  be  capable  of  providing  effective  support.  The 
development  of  the  OFP  support  system  for  the  F-16  is  being  performed 
primarily  by  contract.  Modifications  to  the  OFP's  and  the  support 
system  after  PMRT  is  to  be  performed  by  a  mix  of  organic  and  con¬ 
tractor  personnel.  The  OFP's  are  to  be  supported  by  MMECA  while 
the  facilities  are  to  be  supported  by  MMETA.  Programming  support 
is  to  be  provided  by  ACDC  and  contractor. 

The  F-16  ECS  support  facility,  although  not  completed,  conforms 
with  the  AISF  concept.  Since  this  facility  is  not  yet  operational  the  full 
impact  of  multi-national  support  needs  cannot  be  assessed.  As  the 
F-16  weapon  system  matures  and  increases  in  use  by  participating 
nations  or  through  Foreign  Military  Sales  (FMS)  the  AISF  capability  will 
of  necessity  undergo  a  corresponding  change.  Based  on  planning  docu¬ 
ments  the  capability  of  the  AISF  to  support  the  requirements  is  pre¬ 
sented  in  Table  4-4. 

4.3  F/RF-4  WEAPON  SYSTEM  DESCRIPTION 

The  F/RF-4  is  a  twin  engined,  high  performance  fighter  bomber. 

Its  primary  mission  role  is  tactical  strike  and  air  defense  for  the  F-4E 
and  reconnaissance  and  electronic  countermeasures  for  the  RF-4C. 

Both  aircraft  are  undergoing  Class  V  modifications  to  replace 
analog  computer  systems  with  digital  systems.  The  first  modification, 
commonly  referred  to  as  the  digital  LRU-1  (air  combat  maneuvering). 


Table  4-4.  F-16.  Support  Status 


Requirements 

Findings /Remarks 

ECS  Change 

Procedures  will  follow  OO-ALC  software  change 
process.  Change  candidates  will  be  subjected  to 
cost  estimates,  necessity,  and  benefits  criteria. 
Currently,  a  fixed  level  of  resources  is  planned. 

Change  Analysis 
and 

Specifications 

AFR  800-14  is  being  used  to  establish  procedures 
for  accepting,  analyzing,  and  specifying  changes. 
Cost  estimates  and  risk  assessments  are  made 
organically  on  each  change.  Specifications  are 
prepared  for  each  change  whether  it  is  done 
organically  or  with  contractor  support. 

Engineering 
Development  and 
Unit  Test 

Individual  stands  exist  for  fire  control  computer 
and  stores  management  system,  though  these  are 
connected  by  1553 A  Bus  in  the  F-l6  aircraft.  A 
separate  dynamic  test  control  is  planned  for  the 
Heads  Up  Display  (HUD).  Hardware  changes 
affecting  the  F-16  avionics  can  be  made  and  tested 
in  the  Avionics  Equipment  Bay  (AEB).  Radar 
changes  can  be  developed  and  unit  tested  in  a 
radar  engineering  stand  being  included  as  a  part 
of  the  support  facility. 

Systems  Inte¬ 
gration  and  Test 

1 

Software  integration  and  test  of  changes  to  the  fire 
control  computer  can  be  performed  on  the  dynamic 
simulation  system.  Hardware  interfaces  between 
the  LRU's  in  the  forward  section  of  the  F-16  and 
the  FCC  will  also  be  tested  in  the  DSS/AEB  support 
facility.  Final  systems  test  will  utilize  a  flight 
test  aircraft. 

Change 

Documentation 

The  ECS  documentation  for  the  F-16  will  be  base¬ 
line  in  phases.  This  documentation  will  be  done 
manually. 

Certification 

and 

Distribution 

The  certification  and  distribution  will  be  the 
responsibility  of  the  system  manager  once  the  F-16 
is  transitioned  to  OO-ALC. 
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replac  es  the  analog  computer  in  the  APQ-120  fire  control  radar  with 
a  16K  word  W estinghouse  minicomputer.  The  second  modification, 
known  as  ARN-101  (digital  modular  avionics  system),  replaces  the  ASN-46A 
navigation  computer  set,  the  ASN-56  inertial  navigation  set,  and  in  the 
F-4E,  the  ASQ-91  weapons  relea  e  computer  set. 

4.3.1  F/RF-4  Embedded  Computer  System 

The  AN/ARN-101  system,  which  will  be  the  primary  navigation 
system  for  the  F-4E  and  RF-4C,  employs  a  central  digital  computer, 

(Lear  Siegler  LS-52,  64K),  a  signal  data  converter,  a  Loran  receiver, 
a  digital  Inertial  Measurement  Unit  (IMU),  and  a  three  axis  H-field 
Loran  antenna .  On  the  RF-4C,  see  Figure  4-12,  the  AN/ARN-101 
interfaces  with  the  AN/APQ-99  Forward  Looking  Radar  (FLR),  the 
AN/ASQ-154  data  display  set,  and  related  dedicated  reconnaissance  sub¬ 
systems.  On  the  F-4E,  see  Figure  4-13,  the  AN/ARN-101  interfaces 
with  the  AN/APQ  Fire  Control  Radar  (FCR),  the  AN/ASG-22  Lead 
Computing  Optical  Sight  System  (LCOSS),  and  the  Target  Identification 
System  Electro-Optical  (TISEO)  for  weapon  delivery  systems.  The 
operational  flight  programs  in  each  aircraft  include  interface  with  the 
PAVE  TACK  system. 

The  APQ-120  (Digital  LRU-1),  see  Figure  4-14,  a  one-for-one 
replacement  for  the  analog  LRU-1,  operates  in  five  modes;  Visual 
Identification  (VI)  used  for  identification  and  refueling.  Long  Range 
Intercept  (LRI),  Air  Combat  Maneuver  (ACM),  Counter  Countermeasures 
(CCM)  and  search.  Figure  4-15  shows  a  simplified  diagram  of  the 
F /RF -4  embedded  computer  system, 

4.3.2  F/RF-4  OFP  Change  Process 


The  normal  OFP  update  cycle  is  designed  for  correction  of  a 
number  of  deficiencies  with  a  new  OFP  version  to  be  released  approxi¬ 
mately  once  each  18  months.  OFP  changes  are  to  be  consolidated  for 
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Figure  4-13.  F-4E  Interfaces  and  Systems 
External  to  the  ARN-101 
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Figure  4-14.  Interfaces  and  Systems  External  to 
APQ-120  Digital  LRU-1 
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•  ALTIMETER  (RF-4C  ONLY) 

•  RADAR  (RF-4C  ONLY) 

•  ARMAMENT  RELAY  PANEL 

•  DATA  LINK 

•  PAVE  TACK 

•  MAVERICK  AND  TISEO  (F-4E  ONLY) 

•  PHOTO  RECONNAISSANCE  EQUIPMENT 
(RF-4C  ONLY) 

•  ATTITUDE  DIRECTOR  INDICATOR 

•  AUTOMATIC  FLIGHT  CONTROL 

•  HORIZONTAL  SITUATION  INDICATOR 

•  BEARING  DISTANCE  READING  INDICATOR 

•  FLIGHT  DIRECTOR 

•  CENTRAL  AIR  DATA 

•  TEST  AND  RECORDING  EQUIPMENT 

•  BUILT-IN-TEST 


Figure  4-15.  F/RF-4  Embedded  Computer  System 
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periodic  updates  and,  when  possible,  the  block  update  is  to  be  synchronized 
to  hardware  updates.  The  18  month  block  update  cycle  is  to  be  accomplished 
by  overlapping  the  various  development  schedules.  The  envisioned  OFP 
block  change  cycle  is  essentially  the  same  as  that  for  the  F-16  shown 
previously  in  Figure  4-9  and  Table  4-3. 

4.3.3  F/RF-4  OFP  Support  Interfaces 

The  system  manager  is  responsible.  OO-ALC  organizational 
interfaces  are  the  same  as  for  the  F-16,  see  paragraph  4.2.3. 

4.3.4  F/RF-4  OFP  ECS  Hardware  Support 

Hardware  support  will  follow  standard  AFLC  procedure  which 
was  previously  described  for  the  F -16,  see  paragraph  4.2.4. 

4.3.5  F/RF-4  OFP  ECS  Software  Support 

The  support  facilities  for  the  F-4E  and  RF-4C  OFP's  are  nearing 
completion  and  are  colocated  in  building  1204  at  Ogden  ALC.  Separate 
dynamic  simulation  systems  (referred  to  as  dynamic  simulation  area 
by  Ogden  personnel)  and  static  test  stands  are  being  developed  for  the 
LRU-1  (air  combat  maneuvering)  and  the  AN/ARN-101  (digital  modular 
avionics  system).  These  engineering  laboratories  which  are  described 
in  the  following  paragraphs  consist  of: 

•  Off-line  computer  support 

•  Dynamic  simulation 

•  Avionics  integration 

•  Instrumented  flight  test  aircraft 

•  Subsystem  test 

4.3. 5.1  Off-line  Computer  Support 

The  off-line  computational  support  required  for  changing /modifying 
the  F-4E  and  RF-4C  OFP's  will  be  provided  by  the  General  Purpose 
Computer  Complex  (GPCC).  The  GPCC  consists  of  an  Ogden  ALC  based 
IBM  360-65. 


4.3. 5.2  Dynamic  Simulation 

Separate  dynamic  simulation  systems  are  provided  for  the  LRU-1 
(air  combat  maneuvering)  and  the  AN/ARN-101  (digital  modular  avionic 
system).  Each  simulation  system  equipment  configuration  consists  of 
simulation  host  processors,  special  interface  hardware,  the  actual 
flight  computers  with  their  OFP's,  and  an  operator  test  station.  The 
major  elements  of  the  air  combat  maneuvering  dynamic  simulation 
system  is  shown  in  Figure  4-16.  The  AN/ARN-101  system  is  shown  in 
Figure  4-17.  Figure  4-18  is  a  simplified  version  of  the  combined 
dynamic  simulation  systems.  Also  shown  in  the  figure  is  the  static  test 
stand  which  is  a  stand  alone  element  and  is  discussed  in  the  following 
paragraph.  It  is  shown  here  for  ease  of  comparing  the  AISF  elements 
between  the  representative  support  systems. 

4.3.  5.3  Avionics  Integration 

Two  separate  Static  Test  Stands  (STS)  are  used  for  control  and 
monitoring  of  the  Air  Combat  Maneuvering  (ACM)  and  AN/ARN-101 
operational  flight  programs.  The  STS  is  used  for  avionics  integration 
and  subsystem  testing  by  providing  the  capability  for  data  input/output, 
run/halt  control,  memory  and  register  accesses,  and  control  functions. 
The  testing  is  accomplished  by  halting  the  computer  for  data  input/output 
as  opposed  to  dynamically  providing  environmental  simulation. 

Figures  4-19  and  4-20  show  the  static  test  stands  for  the  ACM  and 
AN/ARN-101  operational  flight  programs. 

4 . 3 .  5 . 4  Instrumented  Flight  Test  Aircraft 

Ogden  ALC  plans  for  use  of  two  test  aircraft;  an  F-4E  equipped 
with  AN/ARN-101  ACM  and  PAVE  TACK  kits,  and  an  RF -4C  equipped 
with  AN/ARN-101.  The  aircraft  are  to  be  assigned  to  the  Specialized 
(Test)  Engineering  R ranch  (MMET)  and  be  instrumented  to  facilitate 
testing  for  system  engineering,  failure  analysis,  prototyping  and  support 
equipment.  The  Utah  test  and  training  range  will  be  used  for  the 
majority  of  flight  tests  and  data  reduction  and  analysis  will  be 
accomplished  on  the  IBM  360-65. 
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and  Static  Test  Stand 


Figure  4-19.  LRU-1  ACM  Static  Test  Stand 
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Figure  4-20.  AN/ARN-101  Static  Test  Stand 


Subsystem  tost  will  bo  accomplished  on  the  sialic  tost  stands. 

See  paragraph  4.  3.  5.  3  (Avionics  Integration). 

4.3. 5.6  Assessment  of  F/RF-4  Support  Posture 

The  F-4  support  systems  include  individual  AISF's  to  support  the 
ARN-101,  PAVE  TACK  and  ACM  digital  computer,  static  test  stands 
for  the  ARN-iOl  and  ACM  computers,  plus  specialized  software  for  all 
three  avionics  computers.  These  tools  represent  the  latest  technology 
for  software  change  and  testing.  Software  changes  can  proceed  from 
development  testing  on  a  static  test  stand  through  extensive  verification 
on  a  dynamic  simulation  facility  for  the  ARN-101  and  ACM  computers 
and  on  an  AISF  for  the  PAVE  TACK  computer.  Hardware-to-software 
interfaces  and  system  tests  involving  the  hardware  must  be  performed 
on  an  F-4  aircraft  since  a  limited  set  of  group  B  equipment  is  used 
in  the  AISF.  This  differs  from  the  F-lll  where  the  PAVE  TACK/F-111 
interface  can  be  tested  in  an  AISF.  Automated  tools  for  configuration 
management  will  exist  for  the  PAVE  TACK  at  WR-ALC  and  are  being 
developed  for  the  ARN-101  and  ACM  at  OO-ALC.  A  word  processor 
is  being  used  for  documentation  of  the  ARN-101  and  ACM  support 
facilities,  while  the  operational  flight  programs  and  technical  orders 
are  manually  maintained.  The  development  of  the  AISF's  is  managed 
and  controlled  by  government  personnel  with  the  support  of  on  site  con¬ 
tractor  personnel  at  both  ALC's.  Experience  levels  on  the  AISF's  are 
high  for  the  government  managers  and  the  contractor  support  personnel. 
Support  software  that  would  enhance  the  analyses  of  test  data  from  the 
AISF's  and  flight  tests  is  limited  at  OO-ALC,  though  some  development 
is  under  way  and  more  is  planned.  The  support  software  for  flight  test 
of  the  PAVE  TACK  is  currently  under  way  and  is  based  on  the  F-15  system 
Accessibility  to  off-line  processors  for  development  tools  has  been 
restricted  in  the  past  but  is  improving  for  the  ARN-101  and  ACM. 


Support  of  the  AISF's  will  be  a  combination  of  level-of-effort  and 
specialized  support.  The  combination  of  static  test  stands  and  AISF's 
is  designed  to  provide  effective  software  support  for  OFP  changes  for 
the  ARN-101  and  ACM.  System  integration  of  the  F-4,  including 
hardware-to-hardware  and  hardware- to -software  testing  for  the  F-4 
will  be  performed  in  the  flight  test  aircraft. 

The  F/RF-4  support  facilities  do  not  entirely  conform  with  the 
AISF  concept  in  that  an  integration  hot  bench  capability  is  not  currently 
planned.  The  use  of  flight  test  to  accomplish  this  function  is  not  deemed 
as  capable  or  cost  effective  when  compared  to  a  ground-based  laboratory. 
The  F/RF-4  AISF  is  scheduled  to  become  operational  in  1980  and  as 
operational  needs  mature  it  is  expected  that  support  requirements  very 
similar  to  those  experienced  by  the  F/FB-111  AISF  will  dictate  a  more 
capable  F/RF-4  AISF.  Findings/remarks  relevant  to  the  planned 
capability  to  support  the  requirements  are  contained  in  Table  4-5. 

4.4  MINU T E MAN  III  (WS-133AM)  ICBM  SYSTEM  DESCRIPTION 

The  Minuteman  WS-133AM  weapon  system  description  is  presented 
below.  The  WS-133B  weapon  system  description  has  been  omitted  since 
it  is  very  similar  to  but  simpler  than  Minuteman  III.  The  Minuteman  III 
weapon  system  can  deliver  thermonuclear  warheads  to  pre-selected 
targets  from  hardened,  dispersed  launchers  located  in  the  United  States. 
Launcx;  commands  originate  at  hardened,  manned  Launch  Control 
Facilities  (LCF's)  and  reach  distant  Launch  Facilities  (LF's)  via  a 
hardened,  underground  cable  system.  Launch  command  messages  may 
also  originate  from  an  Airborne  Launch  Control  Center  (ALCC).  The 
ground  electronics  system  provides  the  LCF  operational  controls  and 
command /status  communication  links  with  each  LF. 

The  weapon  delivery  system  ;s  the  Minuteman  solid  propellant 
LGM30G  missile.  The  guidance  control  unit  of  each  missile  contains 
four  sets  of  target  parameters,  each  of  which  controls  the  trajectories 
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Table  4-5.  F/RF-4  Support  Status 


R  equi  rt-mcn!  s 

Finding  s  /  R  ema  rk  s 

ECS  Chans e 

Procedures  art-  being  established  to  support  upcoming 
modifications  to  Operational  Flight  Programs  (OFP) 
for  ARN-101  Air  Combat  Maneuvering  (ACM)  and 

PAVE  TACX  computers.  Simulation  support  facilities 
are  in  final  stages  of  development  while  other  tools 
(  e.  g.  ,  Into  rpretive  Computer  Simulation  and  Static 

Test  Stands)  are  operational.  After  PMRT,  changes 
will  be  negotiated  with  user  against  a  set  of  essentially 
fixed  organic  resources  for  OFP  modifications  and 
more  flexible  contractor  support.  ARN-101  and  ACM 
changes  will  be  made  at  QO-ALC  while  PAVE  TACK 
changes  will  be  made  at  WR-ALC. 

Change  Analysis 
and 

Specification 

AFR  800-14  has  been  used  to  formulate  procedures 
that  will  be  used  for  software  modifications  and  as 
documentation  guidelines.  Documentation  of  the 

ARN-101,  ACM  and  PAVE  TACK  OFP's,  and  the 
majority  of  support  facilities  generally  follow  these 
regulations  but  wide  variances  exist  in  quality  and 
quantity  of  documentation.  Procedures  for  change 
analysis  at  both  ALC's  emphasize  the  Computer 

Program  Configuration  Sub-Board  (CPCSB)  as  the 
approving  authority  for  changes. 

Engineering 
Development  and 
Unit  Test 

Procedures  that  have  been  developed  to  f->llow  standard 
development  practices.  Changes  for  the  ARN-101  and 

ACM  OFP  proceed  through  static,  dynamic  simulation, 
and  flight  tests.  A  set  of  standardized  tests  is  planned 
for  the  ARN-101  and  ACM  AISF's  to  detect  unspecified 
interaction  and  unexpected  results.  The  PAVE  TACK 
changes  will  be  developed  and  tested  on  the  PAVE 

TACK  AISF  prior  to  flight  testing.  Testing  of  the 
ARN-101/PAVE  TACK  interface  is  currently  planned 
to  be  performed  in  the  flight  test  aircraft.  The  F-lll/ 
PAVE  TACK  interface  can  be  tested  in  the  F-lll 

AISF  prior  to  flight  testing.  This  includes  hardware- 
to-hardware  and  systems  tests. 

Change 

Documentation 

ECS  documentation  will  be  baselined  at  PMRT. 

Support  system  documentation  will  be  baselined  at 
completion  of  basic  system.  Documentation  for  OFP's, 
technical  orders,  and  support  systems  is  being  per¬ 
formed  by  contractors  and  organic  personnel.  The 
documentation  is  primarily  manual. 

Certification  and 
Dist  ribution 

The  system  manager  will  certify  and  approve  revised 
programs  for  all  three  avionics  systems. 

of  as  many  as  three  warheads.  A  specific  target  set  is  designated  for 
use  prior  to  launch.  A  launch  can  occur  a  few  seconds  after  the  receipt 
of  the  launch  command  or  be  delayed  for  several  hours. 

The  basic  squadron  configuration  consists  of  50  unmanned  missile 
LF's  and  five  manned  LCF's.  Automatic  LF  status  reports  and  LCF 
self-checks  inform  the  LCF  status  console  operator  of  equipment  mal¬ 
functions  by  means  of  visual  and  audible  alarms.  The  LCF  operator 
relays  fault  indications  to  the  maintenance  control  center  at  the  strategic 
missile  support  base  where  corrective  actions  are  directed. 

The  primary  mission  of  the  ICBM  system  is  to  defer  acts  of  foreign 
aggression.  To  accomplish  this  mission,  the  ICBM  system  is  designed 
to  survive  an  act  of  aggression  by  a  foreign  power  and  still  be  able  to 
function  in  a  post-attack  environment. 

Minuteman  is  currently  deployed  in  four  versions,  two  each 
for  Minuteman  II  and  Minuteman  III.  While  each  version  is  slightly 
different  in  the  ECS  systems,  incorporated  they  are  all  the  same  in 
basic  functional  requirements  and  are  managed  the  same.  While 
MX  and  Cruisewill  no  doubt  be  different,  the  basic  ECS  management 
requirements  outlined  here  for  Minuteman  will  apply. 

4.4.1  Minuteman  III  Embedded  Computer  System 

The  version  of  Minuteman  III  specified  as  WS-133-AM  contains 
five  embedded  computer  systems  and  one  general  purpose  automated 
data  processing  system  that  provides  data  for  the  operational  system. 
These  systems  are  described  in  Sections  4. 4. 1 . 1  through  4. 4. 1 . 5. 

Table  4-6  shows  the  WS-133-AM  equipment  identification. 

4.4. 1.1  Airborne  ECS 

The  airborne  ECS  is  based  on  the  Autonetics  D-37D  serial  computer. 
The  software  is  comprised  of  two  separately  configured  computer 
programs,  the  first  of  these  programs  is  the  Operational  Ground  Program 
(OGP).  This  program  performs  the  functions  of  command  and  control, 
establishment  of  the  inertial  reference,  and  fault  monitoring  and  reporting. 
While  this  program  executes  only  while  the  missile  is  in  the  launcher,  it 
could  be  categorized  as  an  operational  flight  program. 
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Table  4-6.  ICBM  (WS-133-AM)  Equipment 
Identification 


Computer 

Where  Used 

Softwa  re 

IBM  360 

HQ  SAC 

MOTP,  STSS,  EPP 

WSC 

LCF 

MOTP,  EPP,  OEP 

DPU 

ALCC 

DPU  Operational /Daily 
Exercise  Program 

D37-D 

Airborne 

OFP,  OGP 

D37-C 

Command  CIV  at 

HQ  SAC 

D37-D 

SMSB  CIV 

CIV  (E) 

The  operational  flight  program  performs  the  functions  of  navigation 
and  flight  control.  This  program  executes  only  after  the  OGP  has 
satisfied  the  requirements  of  flight  preparation,  launch  command 
validation,  and  launch.  Once  control  is  transferred  to  the  flight  pro¬ 
gram  it  never  returns  to  the  ground  program. 

4.4. 1.2  Command  and  Control  ECS 

The  command  and  control  ECS  is  based  on  a  Univac  special  purpose 
computer  identified  as  the  Weapon  System  Controller  (WSC)  that  resides 
in  the  Launch  Control  Center  (LCC)  and  interfaces  with  the  operator  on 
one  side  and  the  weapon  system  on  the  other.  The  software  set  consists 
of  the  Operational  Executive  Program  (OEP),  the  Target  Constants 
Generation  (TCG)  program  and  the  Execution  Plan  Program  (EPP). 

The  OEP  performs  command  generation  and  transmission  functions 
under  operator  manual  control  as  well  as  automatic  status  interogation 
and  monitoring  functions  in  real  time.  It  also  provides  service  routines 
for  the  TCG  and  EPP  to  operate  in  a  background  mode. 


rp 


The  TCG  program,  under  control  of  the  OEP,  translates  target 
coordinate  information  into  steering  and  control  constants  that  will  be 
used  by  the  airborne  computer  to  fly  to  a  specific  target.  This  program 
executes  in  a  variable  area  of  computer  memory  in  a  background  mode. 

It  normally  resides  with  the  EPP  and  their  respective  data  bases  on  an 
auxiliary  bulk  store  memory  device  adjacent  to  the  WSC. 

The  EPP  generates  a  series  of  launch  delay  and  target  selection 
options  for  use  by  the  OGP  in  establishing  preplanned  war  execution 
options.  The  program  operates  in  the  background  under  control  of  the 
OEP  in  the  same  resident  memory  area  as  the  TCG  program. 

4.4. 1.3  Secure  Code  Processing  ECS 

Two  ECS's  are  provided  in  the  system  to  prepare  secure  code 
material  for  use  by  the  weapon  system.  These  codes  are  used  to  validate 
legal  orders  for  launching  the  Minuteman  force.  The  ECS  systems  are 
identified  as  the  Command  Code  Inserter  Verifier  (CCIV)  that  uses  the 
Aufconefcics  D-37C  computer  to  process  the  code  material  for  the  entire 
force  and  is  located  at  Strategic  Air  Command  Headquarters.  The  Code 
Inserter  Verifier  (CIV)  using  the  D-37D  and  WSC  computers  distributes 
specific  code  material  to  individual  LCF's  and  Launch  Facilities  (LF's) 
as  well  as  formatting  unique  launch  point  data  for  each  LF.  A  CIV  is 
located  at  each  Strategic  Missile  Support  Base  (SMSB)  that  is  geo¬ 
graphically  located  with  each  missile  wing. 

4.4. 1.4  Airborne  Launch  Control  Center  ECS 

The  Airborne  Launch  Control  Center  (ALCC)  is  an  ECS  that  pro- 
)  |  vides  a  backup  launch  capability.  The  Data  Processing  Unit  (DPU) 

|  executes  software  that  provides  test  and  secure  enable  and  launch 

messages  to  Minuteman  LF's. 
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The  SAC  Targeting  Support  Software  (STSS)  executes  on  an 
IBM  360  system  at  SAC  headquarters  and  provides  the  data  bases  that 
are  used  at  the  LCF  to  generate  target  constants  by  the  TCG  and 
execution  plan  options  by  the  EPP. 

4.4.2  Nuclear  Safety  Support  Criteria 

The  total  number  of  embedded  computer  systems  that  control 
nuclear  weapons  is  small,  but  due  to  the  seriousness  of  a  nuclear  incident 
or  accident,  too  much  emphasis  cannot  be  placed  on  the  need  for  stringent 
support.  Only  two  operational  systems  fall  into  this  category  current 
with  two  new  systems  in  development.  The  Minuteman  ICBM  system  in 
four  versions  and  the  Titan  II  ICBM  system  are  currently  operational 
while  ICBM  MX  and  air  launch  and  ground  launch  cruise  missiles  are 
under  development. 

Embedded  computer  systems  that  have  a  first  or  second  level  inter¬ 
face  to  a  nuclear  weapon  as  defined  in  AFR  122-9  are  few  in  number,  but 
it  is  readily  apparent  that  their  sensitivity  is  critical.  This  type  of 
system  over  the  past  fifteen  years  has  caused  great  concern  to  the  safety 
community  and  has  resulted  in  implementation  of  policy  and  programs 
that  minimize  the  risk  of  an  embedded  computer  system  contributing  to  a 
nuclear  incident  or  accident.  These  policies  are  well  implemented  in 
ballistic  missile  system  acquisitions  in  the  Air  Force  Systems  Command 
and  are  carried  over  to  the  Air  Force  Logistics  Command  at  OO-ALC 
for  the  Minuteman  ICBM.  The  following  definitions  are  provided  to  form 
a  common  basis  of  understanding  for  discussion  of  nuclear  weapon  system 
control  ECS  support: 

•  Nuclear  weapon  control  software  -  programs  that  execute 
in  embedded  computers  which  have  a  first  or  second 
level  interface  with  a  nuclear  weapon. 

•  first  level  interface  -  any  software  used  by  automata 
v.hich  control  critical  function  of  a  nuclear  weapon. 


•  Second  level  interface  -  any  software  used  by  automata 
which  respond  to  or  transmit  information  to  automata 
having  a  first  level  interface. 

•  Automata  -  class  of  sequential  machines  which,  by 
alternation  of  internal  state,  are  capable  of  performing 
logical,  computational,  or  repetitive  routines.  Examples 
are  automatic  processors,  microprocessors,  computers, 
decoders,  controllers,  and  where  specifically  designated, 
their  associated  peripheral  equipment. 

Of  the  four  NWSC  systems  that  are  the  AFLC  support  responsibility, 
the  system  described  in  this  section  is  representative  of  the  category  in 
its  present  state.  The  intent  of  this  section  is  to  describe  a  sample 
weapon  system  and  the  ECS  support  systems.  The  weapon  system  chosen 
is  the  Minuteman  III  version  of  the  WS-133-AM  ICBM  system.  The 
support  system  consists  of  the  aggregate  of  test  facilities  at  OO-ALC 
generally  identified  as  the  Hill  engineering  test  facility. 

4.4.3  Minuteman  Software  Change  Process  and  Interface 

The  weapon  system  is  made  up  of  two  basic  parts:  the  airborne 
system  consisting  of  the  missile,  and  the  ground  system  consisting  of 
the  missile  launch  facility  and  the  launch  control  facility.  Each  of  these 
segments  has  operational  software,  which  is  supported  under  contract, 
as  an  integral  part  and  for  that  reason  procedures  are  required  to  maintain 
a  firm  configuration  baseline.  The  software  change  process  is  shown  in 
Table  4-7. 

A  Minuteman  Operational  Software  Working  Group  (MOSWG)  is 
organized  review  all  activities  involved  in  the  maintenance  and  update 
of  Minuteman  operational  tapes/programs  as  well  as  the  weapon  systems 
software  associated  technical  orders  and  supporting  documentation.  The 
group  ensures  that  all  changes  to  existing  operational  software  are  com¬ 
patible  with  other  weapon  system  software,  overwrite  software,  trainers, 
depot  test  equipment,  etc.,  and  that  the  weapon  system  mission  require¬ 
ments  are  maintained.  The  MOSWG  can  only  recommend  changes  to  the 
operational  software  to  the  OO-ALC/CPCSB  or  SAC/CCB. 
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Table  4-7.  Minuteman  Software  Change  Process 


Phase /Support 
R  equirement 


Engineering  Activity  and  Primary  Output/ 
Control  Documentation 


Deficiency 
Report /Change 
Procedures 


Submittal  of  change  requests.  Most  frequently,  changes 
originate  through  deficiency  reports  submitted  in 
accordance  with  AFR  74-6.AFLCR  800-21,  and  T.O. 

003  5D-54.  All  change  activity  is  controlled  through 
the  Material  Improvement  Program  (MIP)  and  tracked 
through  the  G026  reporting  system.  The  deficiency 
report  categories  which  apply  are: 


•  Category  I  MDR  -  report  of  an  emergency  con¬ 
dition  which  presents,  or  has  the  clear  potential 
to  present  an  unacceptable  safety,  operational, 
or  maintenance  hazard. 


•  Category  II  MDR  -  deficiencies  which  are  related 
to  the  errors  generated  in  design  and  production 
or  changes  that  could  upgrade  the  operation. 

New  capability  programs  will  be  generated  in 
accordance  with  the  procedures  of  AFR  57-1. 


Change 

Evaluation  and 

Classification 

Assessment 


Deficiencies  which  are  identified  in  Minuteman 
operational  software  managed  by  OO-ALC  will  be 
evaluated,  assessed,  and  processed  in  accordance 
with  the  procedures  outlined  in  the  O/SCMP  and  in 
AFLCR  66-15,  OOALCR  66-3  and  800-3,  and 
DMMOI  81-3.  Briefly,  the  process  will  be  as 
follows: 


•  Identification  of  deficiency  reported  to  OO-ALC/ 
MMMS  by  user,  contractor,  or  OO-ALC  agencies. 

j  •  OO-ALC/MMMS  determines  the  action  point, 
j  initiates  a  MIP,  and  forwards  the  MDR  to  MMGR. 

j  •  OO-ALC/MMGR  evaluates  the  MIP,  responds  to 
I  the  originator  within  the  established  time  schedule 

as  defined  in  the  aforementioned  publications, 
updates  MIP  actions  with  MMMS  as  required, 
and  requests  MMEC  support. 

•  OO-ALC /MMEC  evaluates  the  MIP,  prepares  a 
CEP  or  EPR  as  required;  evaluates  the  ECP; 
prepares  the  AFLC  Form  75,  the  OO-ALC  Form 
446,  and  a  CEP;  and  forwards  the  package  to 
MMGR. 


Table  4-7.  Minutcman  Software  Change  Process  (Continued) 


Phase /Support 
Requirement 


Change 

Evaluation  and 
Classification 
Assessment 
(Concluded) 


Engineering  Activity  and  Primary  Output/ 
Control  Documentation 


OO-ALC/MMGR  then  prepares  AFLC  Forms  75 
and  873,  a  staff  study.  Environmental  Impact 
Statement  (AFR  19-2),  and  budgetary  cost 
information.  These  items  are  consolidated  with 
the  MMEC  package  and  retained  for  presentation 
to  the  MOSWG.  The  ICWG  is  also  provided 
documentation  for  interface  evaluation. 

The  ICWG  evaluates  the  change  for  weapon  system 
interfaces  impact  and  provides  the  CPCSB  with  a 
recommendation  for  approval  or  disapproval. 

The  MOSWG  reviews  the  proposed  change  and 
provides  recommendations  to  the  CPCSB. 

The  CPCSB  approves  or  disapproves  the  change 
for  forwarding  to  the  AFLC/CCB. 


Deficiencies  which  are  identified  in  Minuteman 
operational  software  managed  by  SAC  are  evaluated, 
assessed,  and  processed  in  accordance  with  SAC 
established  procedures  and  reviewed  by  the  MOSWG 
and  CPCSB  as  stated  in  the  O/SCMP. 


Emergency 

Change 

Procedures 


Configuration  changes  which  are  of  an  emergency 
nature  are  processed  within  the  time  frames  established 
in  MIL  -STD  480  and  T.O.  00-35D-54, 


Coordination 


•  Coordination  with  change  originator.  Coordination 
on  Category  I  MDR's  is  in  accordance  with  T.O. 
0035D-54,  Section  VII. 

•  Coordination  on  Category  II  MDR's  is  in  accordance 
with  T.O.  00-35D-54,  Section  VIII. 

•  Coordination  with  user.  The  SM  apprises  Hq  SAC 
of  acknowledgement  and  interim  or  final  responses 
to  all  Category  I /III  MDRS,  ECP's,  letters,  etc., 
which  affect  Minuteman  operational  software.  If 
an  MDR  is  submitted  in  error  or  if  additional 
information  is  required,  the  corrective  action 

is  negotiated  between  SAC  and  the  SM. 


Table  4-7.  Minuteman  Software  Change  Process  (Continued) 


Phase /Support 
Requirement 


Engineering  Activity  and  Primary  Output/ 
Control  Documentation 


T est  of 

Change  Design 


Development  testing.  Development  testing  is 
accomplished  when  a  particular  routine  has  been 
compiled,  debugged,  and  checked  out  well  enough 
to  allow  successful  execution.  Emphasis  is 
placed  on  exercising  every  instruction,  providing 
accuracy  of  computations,  showing  repeatability 
of  results,  testing  upper,  lower  and  nominal  ranges 
of  data  values,  testing  error  conditions  and  veri¬ 
fying  timing,  sizing,  interfaces  and  data  handling 
characteristics  on  a  routine-by-routine  basis. 
During  this  phase  documentation,  as  specified 
by  the  government,  is  maintained  and  includes 
such  information  as  requirements  interfaces,  pre¬ 
liminary  design,  detailed  design,  test  plans,  test 
procedures,  and  test  results. 

Qualification  testing.  Qualification  testing  is  the 
formal  testing  that  occurs  by  the  developing  con¬ 
tractor  under  government  approved  test  plans. 

All  qualification  testing  is  conducted  using  opera¬ 
tional  software  and  computer  hardware,  that  is, 
the  identical  components  used  in  support  of  the 
system  mission.  Errors  and  other  problems 
discovered  during  this  testing  and  testing  at 
other  facilities,  are  referred  back  to  the  contract 
OPR  for  evaluation  and  direction  for  correction 
as  required.  A  complete  qualification  test  report 
is  prepared  by  the  developer  to  be  used  as  the 
basis  for  the  functional  configuration  audit. 

Integration  testing.  Integration  testing  is  formal 
testing  conducted  by  the  integrating  agency  in 
parallel  with  qualification  testing.  The  integrating 
agency  is  designated  and  an  integration  test  plan 
is  prepared  as  specified  in  the  contract.  Emphasis 
during  integration  testing  is  placed  on  validating 
that  the  requirements  imposed  by  the  higher  level 
specification  are  met.  The  main  purpose  of  vali¬ 
dation  testing  is  to  demonstrate  that  actual  per¬ 
formance  meets  required  performance  with  the 
software  product  functioning  in  as  near  an  opera¬ 
tional  environment  as  practical.  A  complete  inte¬ 
gration  test  report  is  prepared  by  the  integration 
agency  prior  to  release  of  the  program  to  the  field. 
Test  reports  are  reviewed  and  problems  resolved 
by  OO-ALC/MMECM. 


Table  4-7.  Minuteman  Software  Change  Process  (Continued) 


Phase/Support 

Requirement 

Test  of 

Change  Design 
(Concluded) 


Documentation 
and  TCTO 
Generation 


Engineering  Activity  and  Primary  Output/ 

Control  Documentation 

•  Nuclear  Safety  Cross-Check  Analysis  (NSCCA). 

The  nuclear  safety  cross-check  analysis  performed 
on  Minuteman  operational  software  is  one  of  the 
positive  measures  implemented  by  the  Air  Force 

to  fulfill  the  DOD  nuclear  safety  standards.  The 
NSCCA  provides  assurance  that  the  software  as 
designed,  coded,  and  implemented  cannot  con¬ 
tribute  to  accidental,  unauthorized,  or  inadvertent 
activation  of  critical  nuclear  weapon  system 
functions.  This  testing  will  be  performed  by  an 
independent  contractor  appointed  by  OO-ALC/ 
MMECM.  A  full  NSCCA  report  is  prepared  and 
reviewed  prior  to  NWSSG  certification  for  opera¬ 
tional  use  of  the  computer  program.  NSCCA  may 
be  performed  in  parallel  to  a  great  extent  with 
qualification  and  integration  testing. 

•  Operational  Test  and  Evaluation  (OT&E).  Testing 
in  an  operational  environment  is  accomplished  to 
assure  proper  operation  of  a  new  or  modified 
program.  Typical  OT&E  procedures  utilize  a 
larger  number  of  computers  and  expanded  test 
conditions  than  are  found  in  the  aforementioned 
engineering  tests.  SAC  is  responsible  for  pro¬ 
viding  OT&E  requirements  to  OO-ALC /MMECM 
for  incorporation  into  the  contract. 

•  Documentation.  The  data  items  are  specified  and 
generally  consist  of  the  following: 

•  Computer  programs,  data,  and  printouts 

•  Computer  program  development  plan 

•  Interface  control  drawings 

•  Baseline  identification  specifications 

•  U  ser s  manual 

•  Computer  programming  manual 

•  Catalog  and  glossary  of  computer  programs 
and  programming  documentation 

•  Minutes  of  formal  reviews  and  audits 

•  Configuration  management  plan 


Table-  4-7.  Minute-man  Software  Change  Process  (Continued) 


Phase /Support 
Requirement 

Engineering  Activity  and  Primary  Output/ 

Control  Documentation 

Documentation 
and  TCTO 
Generation 
(Concluded) 

•  Version  description  documents 

•  Configuration  index 

•  Change  status  report 

•  Specification  change  notice 

•  Engineering  change  proposal 

•  Test  plans,  procedures  and  reports 

•  TCTO  Generation.  All  OO-ALC  managed  Minute- 

man  operational  software  changes /modifications 
are  announced  in  a  separate  TCTO.  Each  TCTO 
is  assigned  a  degree  of  urgency  at  the  time  of 

CPCSB  approval  as  appropriate.  Three  desig¬ 
nations  of  urgency  are  authorized:  immediate 
action,  urgent  action,  and  routine  action.  The 

AFLC  Form  75  will  serve  as  the  official  record 
of  approval  of  Minuteman  operational  software 

CPCI  changes.  It  is  included  in  the  TCTO  package 
with  the  AFLC  Forms  873  and  875,  and  TCTO 
draft  by  the  MMGR  action  point  to  reflect  tne 
authorization  of  the  TCTO  by  the  appropriate 
approval  authority.  This  package  will  be  prepared 
and  processed  by  the  MMGR  action  point  after 

CPCSB /AFLC /USAF  approval  and  routed  through 
OSHA,  Missile  Safety,  MMGP,  and  MMEC  to  MMED 
for  Minuteman  operational  software  changes. 

(Refer  to  AFLCM  66-14  for  AFLC  Forms  873  and 

875  preparation.)  The  TCTO's  used  to  announce 
changes  to  Minuteman  operational  software  will 
be  funded  under  appropriation  3400,  EEIC  594. 
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Table  4-7.  Minuteman  Software  Change  Process  (Concluded) 


Phase /Support 
Requirement 

Reproduction  and 
Distribution  of 
Magnetic  Tapes 
and  TCTO's 


Engineering  Activity  and  Primary  Output/ 

Control  Documentation 

•  Hq  SAC  (DOMC)  is  responsible  for  reproducing 

all  Minuteman  operational  program  tapes  using  the 
DNS  certified  MYDAC/DUPCOM  computer  pro¬ 
gram  and  will  assure  NSCCA's  are  performed  on 
all  tapes  as  required  by  the  NWSSG,  The  serial¬ 
ization  of  reproduced  and/or  replacement  copies 
of  program  tapes  are  the  responsibility  of  SAC 
as  directed  in  the  TCTO.  Serialization  of 
replacement  copies  for  unserviceable  or  damaged 
tapes  is  the  same  as  the  initial  TCTO. 

•  OO-ALC/MMED  assures  sufficient  copies  of  the 
TCTO  are  provided  to  Hq  SAC  for  distribution  to 
units  with  the  tapes.  Hq  SAC  (DOMC)  is  res¬ 
ponsible  for  distribution  and  accountability  for 
SAC  and  SAC  produced  copies  of  the  tapes  and 
TCTO's  which  are  provided  to  the  units. 


Implementation 


•  Implementation  of  approved  changes  is  by  means 
of  released  TCTO's  and  associated  kits. 


All  Minuteman  op*.1  rational  software  changes  will  bo  processed 
through  the  CPCSB.  The  CPC  SB  will  be'  responsible-  for  final  engineering 
approval  of  all  changes  to  operational  software  and  effects  on  equipment 
and  related  computer  prog  rams/systems  within  the  M.nuteman  weapon 
system  and  will  also  be  responsible  for  final  approval  of  changes,  costs, 
and  testing  for  which  OO-ALC  has  primary  management  responsibility. 

The  Strategic  Air  Command  Configuration  Control  Board  (SAC/CCB)  is 
responsible  for  final  approval,  costs,  testing,  changes  to  system  docu¬ 
mentation,  and  effects  on  equipment  and  related  computer  programs/ 
systems  for  which  SAC  has  primary  management  responsibility. 

4.4.4  Minuteman  II/III  ECS  Support  System 

An  extensive  set  of  support  equipment  exists  at  OO-ALC  under  the 
name  of  the  Hill  Engineering  Test  Facility  (HETF).  This  facility,  used 
to  evaluate  system  level  problems,  provides  the  capability  to  test  all 
of  the  weapon  systems  ground  functions  in  a  near  real  environment. 

While  actual  system  hardware/software  is  used  in  limited  numbers, 
command  and  control  simulators  are  used  to  provide  operational  conditions. 

The  HETF  consists  of  two  structural  launchers,  one  each  of  the 
WS-133-AM  and  WS-133-B  configurations.  Each  LF  is  supported  by  a 
compatible  LCF,  in  an  above  ground  configuration  and  a  squadron  data 
simulator.  The  facility  is  augmented  by  several  guidance  and  control 
facilities  designed  for  software  qualification  testing  that  can  be  electrically 
integrated  into  the  HETF  as  simulated  launch  facilities. 

While  all  Minuteman  operational  software  is  developed  under  con¬ 
tract  to  specific  qualified  contractors,  the  HETF  provides  means  for 
system  and  subsystem  problem  evaluation  as  well  as  integration  and 
qualification  testing  support. 

Throe  basic  test  facilities  exist  at  Hill  AFB  for  Minuteman  system 
testing.  Each  facility  can  be  operated  in  several  configurations  which 
include  varying  amounts  of  real  and  simulated  Minuteman  equipment.  The 
test  facilities  will  bo  used  to  support  operational  software  system  testing 
and  field  problem  isolation  and  resolution.  These  facilities  are  described 
on  the  following  pages. 
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4.4.4. 1  Hill  Engineering  Test  Facility  I 

The  Hill  Engineering  Test  Facility  I  (HETF  I)  is  configured  to 
provide  a  total  test  bed  for  the  Wing  III  and  V  systems.  The  HETF  I 
consists  of  the  following  hardware,  software,  and  test  elements: 

•  Real  LF  and  LCF  equipment 

•  Electronic  LF 

•  Electronic  LCF 

•  Squadron  data  simulator 

•  Operational  software 

•  MOTP  19215 

•  OEP  19214 

•  EPP  19211 

•  OGP  19240 

•  OFP  19243 

•  Instrumentation  system 

•  SETS 

4. 4. 4. 2  Hill  Engineering  Test  Facility  II 

The  Hill  Engineering  Test  Facility  II  (HETF  II)  is  configured  to 
provide  a  total  test  bed  for  the  Wing  VI  systems.  The  HETF  II  consists 
of  the  following  hardware,  software,  and  test  elements: 

•  Real  LF  and  LCF  equipment 

•  Electronic  LF 

•  Electronic  LCF 

•  Squadron  data  simulator 

•  Operational  Software 

•  MOTP  19215  (shared) 

•  OEP  1921 
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•  EPP  19211  (shared) 


•  OGP  19241 

•  OFP  29243  (shared) 

•  Instrumentation  system 

•  SETS 

4.4. 4. 3  Electronic  Test  Facility 

The  Electronic  Test  Facility  (ETF)  is  configured  to  provide 
electrical/electronic  test  bed  for  the  Minuteman  II  Wing,  I,  II,  IV,  and 
ERCS  force  mod  systems.  The  ETF  consists  of  the  following  hardware, 
software,  and  test  elements: 

•  LF  and  LCF  electronic/electrical  systems 

•  NS-17  guidance  system 

•  Squadron  data  simulator 

•  Operational  software 

•  OEP  19200 

•  OGP  19236 

•  OFP  13001 

•  Instrumentation  system 

4.4.5  Minuteman  Test  and  Analysis  Tools/Sites 

This  section  describes  the  analysis  and  test  tools  presently  available 
at  OO-ALC.  These  facilities  include  several  special  purpose  test  labo¬ 
ratories  and  two  general  purpose  computing  facilities.  The  special  pur¬ 
pose  test  facilities  generally  contain  operational  Minuteman  equipment 
interfaced  with  digital  computers  programmed  to  provide  a  simulated 
operational  environment.  The  general  purpose  facilities  include  an  IBM 
360  computer  and  CDC  CYBER  73  computer.  These  facilities  provide 
some  general  support  functions  such  as  plot  programs,  text  editors, 
and  debug  programs,  as  well  as  providing  facilities  for  executing 
simulation  programs. 
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Several  Minuteman  support  software  programs  execute  on  the 
Hill  Air  Force  Base  (HAFB)  IBM  360. 

•  D37C  Assembler 

•  D37D  Assembler 

•  IBM  360  O/S  -  the  HAFB  IBM  360  O/S  provides  a 
FORTRAN  compiler  and  program  execution  monitor 
with  sufficient  debug  capabilities  to  support  program 
development. 

•  Missile  flight  simulation.  Cl  AK48  -  the  Missile  Flight 
Simulation  (MFS)  provides  a  closed  loop  simulation  of 
the  Minuteman  II  flight.  Executing  on  the  IBM  360,  the 
MFS  contains  an  ICS  simulation  of  the  D37C  computer 
and  a  flight  dynamics  simulation.  The  D37C  simulation 
does  not  simulate  the  execution  of  all  D37C  instructions. 

•  SAC  Targeting  Support  Software  (STSS)  -  the  STSS- 
400/600  was  designed  to  provide  SAC  with  the  capability 
to  assemble,  load,  and  simulate  the  execution  of  the 
WSC  MOTP  and  EPP  programs.  The  WSC  simulation 
simulates  only  those  instructions  executed  by  the 
MOTP  or  EPP. 

4. 4.  5.  2  Total  Integrated  System  Capability 

The  Minuteman  II  Total  Integrated  System  Capability  (TISC)  employs 
a  D37C,  two  NOVA  computers,  and  the  following  peripherals: 

•  Operator  interface  (keyboard) 

•  Interchangeable  disk  memories 

•  Paper  tape  reader 

•  Printer 

•  Two  CRT  displays 

•  Calcomp  plotter 


TISC  provides  an  execution  monitor  and  controller  for  D37C  execution. 
This  is  accomplished  through  a  modification  of  the  interconnection  between 
the  D37C  Central  Processing  Unit  (CPU)  and  its  memory  disk.  A  section 


of  one  of  the  NOVA  memories  is  substituted  for  the  P37C  disk  memory. 
This  memory  can  then  be  presented  to  the  D37C  CPU  to  be  operated  on 
properly,  but  not  with  the  D37C  timing  constraints,  since  the  D37C  disk 
is  effectively  removed.  The  second  NOVA  is  used  to  simulate  either  the 
missile  dynamics  for  flight  simulations  or  the  IMU  for  ground  simulations. 
Some  ground  functions  are  not  simulated.  TISC  provides  instruction 
level  diagnostics,  trace,  timing,  save/restart,  and  other  ICS-type 
capabilities . 

4.4. 5. 3  Guidance  and  Control  Test  Sites 

Three  Guidance  and  Control  (G&C)  test  sites  are  available  at  Hill 
AFB.  These  sites  correspond  to  the  basic  weapon  system  configurations 
used  with  Minuteman  II  and  III  missiles.  Each  site  contains  a  Missile 
Guidance  Set  (MGS)  and  associated  ground  equipment,  as  well  as  the 
Communications  and  Processing  Systems  (CAPS). 

Each  test  site  is  equipped  with  breakout  boxes  which  allow  for 
alternating  or  monitoring  all  hardware  signal  transmissions.  CAPS 
provides  both  software  diagnostic  and  simulation  features.  CAPS  has 
the  capability  to  monitor  and  present  to  the  analyst  the  contents  of 
selected  D37  memory  locations.  In  addition,  CAPS  has  the  capability 
of  keying  its  responses  to  the  execution  of  specific  locations,  the  con¬ 
tents  of  a  location  attaining  a  specific  value,  or  on  time. 

CAPS  can  provide  a  squadron  message  traffic  simulation.  Any 
of  the  G&C  test  sites  can  be  connected  to  the  Electronics  Test  Facility 
(ETF)  to  provide  additional  realism  in  simulating  squadron  data  flow. 

•  G&C  test  site  one  -  contains  an  NS-17  MGS,  flight  con¬ 
trol  hardware,  including  cables,  CSD,  WS-133-AM  LF 
OGE,  and  a  CAPS  configured  to  simulate  both  a  WS-133- 
AM  LCF  and  associate  squadron  message  traffic. 

•  G&C  test  site  two  -  contains  either  an  NS-17  or  an  NS-20 
MGS,  either  Minuteman  II  or  Minuteman  III  flight  control 
hardware,  including  cables,  CSD,  WS-133-AM  CDB 

LF  OGE,  and  a  CAPS  configured  to  simulate  both  a 
WS-133-AM  CDB  LCF  and  associated  squadron  message 
traffic. 
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•  G&C  test  site  three  -  contains  an  NS-20  MGS, 

Minuteman  III  flight  control  hardware,  including  cables, 

CSD,  WS-133B  LF  OGE,  and  a  CAPS  configured  to 
simulate  both  a  WS-133B  CDB  LCF  and  associated 
squadron  message  traffic. 

4.4.  5.4  Squadron  Test  Facilities 

Three  Squadron  Data  Simulators  (SDS)  at  Hill  AFB  provide  the 
capability  to  interface  real  LCF  and  LF  hardware  with  a  system  that 
simulates  the  remainder  of  the  squadron  facilities.  The  squadron 
simulation  function  uses  a  digital  computer  with  disk  storage  and  a  line 
printer.  Squadron  message  traffic  can  be  printed  in  real  time.  The 
capability  to  insert  faulty  message  traffic  also  exists. 

In  addition  to  the  SDS,  two  other  types  of  test  facilities  are  pre¬ 
sented  here.  These  are  launch  control  facility  processor  test  stations 
and  software  evaluation  and  test  systems. 

•  Electronic  Test  Facility  SDS  -  provides  the  squadron 
simulation  for  Minuteman  II  (non-ILCS)  and  ERCS 
missile  systems.  This  HE  configured  SDS  will  also 
simulate  G  missile  systems. 

•  Hill  Engineering  Test  Facility  I  SDS  -  provides  the 
squadron  simulation  for  the  Minuteman  III  Wing  III  and 
V  missile  systems.  This  GIP  configured  SDS  will 
also  simulate  F  missile  systems. 

•  Hill  Engineering  Test  Facility  II  SDS  -  provides  the 
squadron  simulation  for  the  Minuteman  III  Wing  VI 
systems. 

•  Wing  III/V  Launch  Control  Facility  Processor /Test 
Station  -  an  LCF  simulator /monitor  used  to  test 
LCFP/WSC  hardware  and  software  in  an  on-line 

(in  conjunction  with  HETF  I)  or  off-line  (stand  alone) 
environment.  The  LCFP/TS  operates  with  the 
WSC/MCG,  and  SDU  and  simulates  nominal  and  per¬ 
turbed  LCF  equipment  operation.  Automated  test 
scenarios  can  be  generated  off-line  and  then  executed. 
Outputs  made  by  the  WSC  to  the  simulated  equipment 
are  displayed  by  the  LCFP/TS.  The  LCFP/TS  can 
also  be  used  to  modify  WSC  software  programs. 
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•  Wing  VI  Launch  Control  Facility  Processor /Test 
Station  -  provides  capabilities  for  the  Wing  VI  LCFP. 

•  Wing  III/V  Software  Evaluation  and  Test  System  (SETS)  - 
a  high  speed  digital  data  acquisition  and  control  system 
used  to  test  operational  LCFP/WSC  hardware  and  soft¬ 
ware.  SETS  selectively  acquires  data  from  weapon 
system  interfaces  in  a  real  time,  non-interfering  manner. 

Data  are  acquired  selectively  by  two  hardware  interface 
preprocessors  which  are  programmable  by  the  test 
operator.  Acquired  data  are  processed  on-line  by  soft¬ 
ware  in  the  central  data  acquisition  unit  and  stored  for 
for  reduction  on  magnetic  disk. 

•  Wing  VI  Software  Evaluation  and  Test  System  -  provides 
the  capabilities  for  the  Wing  VI  LCFP.  SETS  can  also 
be  used  to  modify  (patch)  any  WSC/MCG  software 
programs. 

4.4.  5.  5  Assessment  of  Minuteman  II/III  Support  Posture 

A  thorough  and  disciplined  approach  to  support  of  Minuteman  II/III 
operational  software  is  being  developed  and  pursued  at  OO-ALC. 
Documentation,  plans,  and  procedures  are  detailed;  extensive  and 
effective  test  tools  and  facilities  are  used.  Air  Force  regulations  and 
MIL-STDS  are  applied  in  an  aggressive  manner.  Coordination  and  inter¬ 
faces  are  closely  monitored.  Skill  levels  vary  but  are  generally  high 
at  both  government  and  contractor  facilities.  The  user  is  actively 
involved.  The  independently  developed  Minuteman  II/III  ECS  support 
concept  and  the  resulting  support  posture  have  evolved  over  a  long  period 
of  time  with  PMRT  occurring  long  after  the  systems  were  operational. 

Also  due  to  these  systems'  role  in  the  nation's  defense  posture  and 
the  user  (Strategic  Air  Command)  being  designated  a  specified  command 
responsive  to  the  Joint  Chiefs  of  Staff  (JCS),  the  support  has  been 
afforded  commensurate  management  attention.  This  is  not  to  say  that 
no  problems  exist,  but  rather  to  say  that  due  to  its  high  visibility  a 
degree  of  aggressiveness,  thoroughness  ,  and  adherence  to  established 
procedure  exists  that  is  not  as  apparent  at  other  support  facilities. 
Comments  related  to  the  support  requirements  are  presented  in 
Table  4-8. 
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Table  4-8.  Minuteman  II/III  Support  Status 


Requirement 

Finding  s/Rema  rks 

ECS  Change 

Detailed  procedures  established  over  a  period  of 
time  were  tailored  for  transition  from  SAMSO 
(now  BMO)  to  OO-ALC. 

Change  Analysis 
and 

Specification 

Activities  and  procedures  are  detailed  and  formal 
with  extensive  user  involvement.  Air  Force  regu¬ 
lations  and  MIL-STD's  are  fully  invoked.  Exten¬ 
sive  use  of  tools  and  analysis  aids. 

Engineering 
Development 
and  Unit  Test 

Primarily  performed  under  contract  to  original 
development  contractor.  Standard  acquisition 
and  development  process  is  used. 

System 

Integration 
and  Test 

Accomplished  primarily  at  Hill  Engineering  Test 
Facility  with  detailed  plans  and  procedures. 

Widely  coordinated  and  tightly  controlled 
interfaces. 

Change 

Documentation 

Documentation  is  thorough  and  complete  with 
responsibilities  clearly  defined. 

Certification 

and 

Distribution 

Accomplished  under  tight  control  with  reproduction 
and  distribution  responsibilities  clearly  defined. 

Nuclear 

Safety 

Procedures  essentially  carried  forward  at  PMRT 
to  OO-ALC  NSCCA  performed  by  independent 
contractor.  Procedures  are  detailed  and 
closely  adherred  to. 
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5.  ASSESSMENT  OF  OFP  SUPPORT  POSTURE 


The  OFP  support  concept  for  aircraft  ECS  has  evolved  since  the 
early  1970's.  It  is  well  understood  within  the  engineering  divisions  that 
are  either  operating  or  establishing  support  facilities.  Implementation 
of  the  concept,  however,  tends  to  vary  with  the  particular  location  of  the 
support  facility.  This  is  attributed  primarily  to  circumstance  at  the 
time  of  the  weapon  system  acquisition  or  modification  in  terms  of  available 
funds/source  of  funds  and  the  level  and  number  of  skilled  personnel 
available  at  the  particular  location.  Another  important  factor  has  been 
the  relative  immaturity  of  the  software  support  discipline  with  attendant 
lack  of  widely  recognized/acknowledged  requirements,  established  policy, 
guidance  and  procedure,  and  experience  as  well  as  a  lack  of  data  in 
government  or  industry  upon  which  to  base  decisions. 

Substantial  progress  has  been  made  and  support  is  being  provided 
but  there  are  differences  in  the  support  approach.  For  example,  the 
A-7D  is  currently  supported  at  China  Lake  NAS  through  a  joint  service 
agreement.  On  site  engineering  support  is  provided  at  China  Lake  with 
management  at  Oklahoma  City  ALC.  The  Air  Force  also  provides  test 
aircraft  and  funds  to  the  U.S.  Navy  on  a  proportional  basis.  Engineering 
support  for  the  F-106  OFP  is  provided  primarily  by  contract.  San  Antonio 
ALC  manages  the  effort  and  provides  test  equipment,  test  aircraft  and 
limited  engineering  support. 

The  F /FB -111  is  supported  at  Sacramento  ALC  and  is  the  first 
and  currently  the  only  Air  Force  operational  aircraft  OFP  support  facility. 
Support  facilities  for  other  major  aircraft  weapon  systems,  such  as  the 
F/RF-4,  F-15,  and  F-16,  are  in  various  stages  of  development  to  meet 
anticipated  support  requirements.  These  facilities,  for  the  most  part, 
are  patterned  after  the  F/FB-111  OFP  support  facility  except  for  a 
planned  reduced  reliance  on  continuing  contractor  support.  Consequently 
their  capability,  when  operational,  is  expected  to  be  equivalent  to  the 
F/FB-111  facilities  except  for  the  F/RF-4  facilities,  which,  if  completed 
as  planned,  will  not  include  a  full  integration  hot  bench  capability. 


Support  facilities  for  missile  systems  are  currently  limited  to 
the  Minuteman  II  and  III.  Support  facilities  for  SRAM  are  in  the  planning 
phase.  The  operational  software  changes  /updates  for  these  systems  are 
accomplished  by  the  original  development  contractor  with  system  engi¬ 
neering  and  integration  and  test  being  accomplished  by  a  combination  of 
government  and  contractor  personnel  primarily  at  OO-ALC.  The  effort 
is  managed  by  OO-ALC  and  the  test  facilities  and  stations  are  collectively 
referred  to  as  the  Hill  Engineering  Test  Facility. 

Support  requirements  for  the  OFP  category  date  back  to  the  A-7D 
and  F/FB-111  facility  development  time  frame.  However,  until  recently 
support  requirements  have  not  been  articulated  sufficiently  in  common 
terms  to  become  established  as  a  fundamental  cornerstone  in  early 
support  system  planning.  This  has  not  necessarily  encouraged  but  it  has 
permitted  re-invention  of  support  requirements  in  some  form  or  other 
by  each  new  Computer  Resource  Working  Group  (CRWG)  as  they  struggled 
to  develop  the  Computer  Resources  Integrated  Support  Plan  (CRISP)  and 
the  Operations /Support  Configuration  Management  Procedures  (O/SCMP). 
This  lack  of  recognition  of  support  requirements  has  also  contributed  to 
the  practice  of  "handing  down"  to  the  support  community  all  or  part  of 
the  facilities  used  during  the  Full  Scale  Engineering  Development  (FSED) 
phase. 

The  support  concept  for  the  OFP  category  has  followed  the  same 
general  path  as  described  above  for  the  support  requirements  and,  as  might 
be  expected,  with  approximately  the  same  results.  A  major  contributor  to 
the  current  problems /issues  in  the  support  of  OFP's  can  be  traced  directly 
to  a  lack  of  firm  requirements  and  support  concept.  Many  of  the  problems/ 
issues  such  as  funding,  organization,  documentation,  configuration  manage¬ 
ment,  and  variations  in  the  facilities  themselves  are  the  result  of  a  case 
by  case  approach  to  OFP  support.  There  are  indications  that  this  approach 
has  worked  quite  well  particularly  if  the  individual  AISF's  are  evaluated 
also  on  a  case  by  case  basis,  but  in  the  aggregate  as  well  as  in  the  future 
the  continued  forced  fitting  of  highly  technical  and  mostly  technology  driven 
support  requirements  into  a  logistics  management  environment  will  surely 
continue  to  result  in  less  than  an  optimized  command-wide  OFP  support 
posture. 


